Saxon

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

It's an interesting idea. I recently implemented a mapping from Saxon onto a third-party object model in which the choices and sequences corresponding to the schema structure existed as explicit nodes, and with that kind of model this would be quite possible. The standard XDM (XPath data model) however doesn't have any such nodes, and this would make it quite hard to define the semantics of an expression like name/sequence(). Also, most of the compositor particles in the schema model don't have names, which would make it quite difficult to navigate the structure. Perhaps a more feasible approach would be a function such as schema-structure() which converts the standard XDM tree into a different XDM tree in which sequence and choice constructs are represented as elements in some special namespace. I can see this being quite useful for some grouping problems. Implementing this is another matter: Saxon's schema validator takes the usual approach of converting the grammar of a complex type into a finite state automaton, and the FSA contains no trace of what the original choices and sequences were. Two quite different grammars can produce the same FSA. I guess that standard compiler-compiler technology has a way of tackling this, but it's not a simple bolt-on. Michael Kay

Legacy ID: #3661894 Legacy Poster: Igor (igorotov)

The main reason we are looking into being able to address compositor particles from XPath is so that using an xpath we can uniquely identify the grouping new elements should be added since there could be many levels and combinations of compositors. Even if the compositors had names we would have to introduce additional levels in the tree to disambiguate between, for instance, an element named sequence and a sequence compositor particle. For this reason I tried to stay away from that: it convolutes the xpath expression. My initial thinking was that it should be possible to generically find the right position to insert an element after or before a specific child element in a way that conforms to the complex content defined by the schema, getting away from explicitly representing compositor particles in the instance tree. The algorithm to insert/remove elements or enable/disable insertions/removals in the UI would then use the complex content of the parent element type to figure this stuff up on the fly. But this does solve the problem of manipulatin a specific child element grouping based on the compositor particle. More specifically on implementing something like schema-structure() or sequence(), choice(), or all(): I found some documentation explaining how to add JAXP1.3 XPath functions, but that didnt seem to help me build a function such as schema-structure() or sequence() I was refering before since there is no NodeInfo context for me to get back to my instance tree (I was hoping it was possible for the sequence() function in /name/sequence() to be able to get the 'name' NodeInfo automatically as the contextItem - is that possible? Or do I have to do something like /person/sequence(name)/firstname ?. I also didnt find any specific documentation on how to create Saxon functions that take a context as a parameter. I was able to figure out the signature of such method but I am not sure how to hook that function up to my XPathEvaluator. thanks for your help!