Saxon

Legacy ID: #5819739 Legacy Poster: Michael Kay (mhkay)

Thanks for trying this out. It turns out to be a case that was missing from my tests. I've got it working now, at any rate on Java - there were a couple of flaws in the design. (a) the static base URI of the XPath expression wasn't being set. That's an easy fix, and you could work around it by using an absolute URI. (b) more seriously, the doc() function is attempting validation of the document referenced. That's probably not a good idea: generally the XSD spec is using untyped XPath expressions to avoid problems of recursion, and I think I should probably follow that lead. Unfortunately, though, the XPath APIs in Saxon don't allow any way of setting whether or not validation should take place except at the level of the Configuration, which of course is too global for this purpose. So I need to add some features to the API (specifically, the ability to set a URIResolver) and invoke them to switch validation off. This is too big a change for a maintenance release, so it will have to wait till 9.2. Michael Kay Saxonica

Legacy ID: #5820305 Legacy Poster: Jesper Tverskov (jesper_tverskov)

(b) more seriously, the doc() function is attempting validation of the document referenced. That's probably not a good idea... Yes, I see the problem, but... I think it could be useful to load also the document being validated in xs:assert. Let us say we have a markup language for multiple choice tests. If we have many questions it is nice to mark them up with sub-headings and even sub-sub-headings. The allowed sub-headings for a subject could be defined at the top of the question set document in a metadata section. When validating the question set, the question set could itself be loaded with doc() in an xs:assert element to test if the sub-headings used are actually defined. Not in the schema but in the file being validated. In this way we could use the same schema to validate not just structure and data types but also the sub-headings for any set of questions and subjects. Cheers, Jesper

Legacy ID: #5832174 Legacy Poster: Michael Kay (mhkay)

Although I've got this working after a fashion, I've realised that the implementation is grossly inadequate because doc() is not maintaining a document pool across XPath expression evaluations, which means that the external document will be reparsed each time. Fixing this requires some thought. Another approach, which is in some ways more general, is to allow variables to be bound in the calling application and referenced from within XPath expressions (not only in xs:assert but also in conditional type assigment). This would allow parameterized validation, so different conditions can be tested depending for example on the life-cycle phase of the instance document. Such a variable could be bound to an external document, giving all the capabilities of a call on doc() without the need to maintain a document pool, but it could also be bound to a simple boolean or string.

Legacy ID: #5844508 Legacy Poster: Michael Kay (mhkay)

For assertions in complex types, it turns out to be reasonably easy to ensure that a Controller (and hence a document pool) is available, so access to external documents is now working for that case, and the document is pooled for the duration of the validation episode. For the assertion facet on simple types it turns out to be much more difficult. There's a general assumption in Saxon that the result of casting is context free, and casting can of course invoke facet checking. Also, simple values are often checked for validity during query, stylesheet, or schema compilation. There are already a few places where the assumption of context-free casting and validation is already stretched, notably where the implicit timezone comes into play, so I might have to relax this eventually. But for the moment it seems too much like hard work, so I will impose the restriction (already there in the XSD spec) that the doc() function cannot be called successfully in an assertion facet. The workaround is to define the assertion on a containing complex type.