[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Can XPath / XSLT be aware of XML Schema content mo
Hi Jerome, > The source and result documents describe both a map containing a > list of points with optional label. However the source document > "flatten" the list. [snip] > So, without being able to do a <xslt:for-each> on the sequence, the > conversion seems to me already quite complex if you consider the > potential abscence of the Label element in the sequence. What you're describing is a classic flat-to-hierarchy grouping problem, and the usual XSLT solution (at the moment) would be to apply templates to all the X elements (since you "know" that they are the first in the list) and within the template for each generate the Point element with the content being a copy of the X element and any Y or Label elements that belong to it. Support for this kind of grouping problem is down on the list of requirements for XSLT 2.0, so there should be some nice way of doing this eventually. But I think saying that the grouping specification is something that you can get from the *schema* is very interesting... In a way, here you're treating the model group in the schema as a kind of regular expression for the XML structure that you have, and using the result of the match on the regular expression to create the structure that you want. I think that's a really powerful way to describe this kind of grouping (though it would probably be more powerful if the "regular expression" was specified using RELAX NG, which is suited to that kind of thing, rather than XML Schema). You could also use it nicely with groups based on position (view a sequence of items as a sequence of pairs of items, for example). I wonder if the WG have considered something like it... >> The more information is available in the data model, the more it's >> tied to a particular schema language. > > So, in your mind where is the right balance ? > Maybe a neutral / generic schema infoset in the XPath data model ? It's a really difficult question to answer. I think that practically and morally(!) XPath/XSLT should support people using different kinds of schema languages, DTDs, or no schema language if they don't need one. But the only thing you can really guarantee about a (grammar-based) schema is that it will contain things that can be considered the declarations/definitions/descriptions of the elements and attributes in the source document. One possibility that would enable you to get hold of whatever information you need, whatever the schema language, is to get hold the element/attribute declarations as element nodes within the schema node tree (you could do a simple mapping from DTDs syntax to XML syntax to get DTD information). You could then use standard location paths to accessing the further details. Given that, it should be possible for people (users, schema-spec-writers or implementers) to define schema-language-specific extension functions that access extra information as required from that element declaration. So I think all the data model needs to do on the structure side is include a link to the element node for an element/attribute declaration in the schema/DTD from an element/attribute node in the instance/source document. On top of that, it seems that the most useful piece of information from a schema is the data type of a text-only element or attribute. The range of possible data types differs across schema languages, and indeed across schemas if you count user-defined simple types in XML Schema. However you still want to be able to do useful things like add a date and a duration easily, and for that XPath has to have some understanding of and hence limit on the data types that it allows. I think the set of XML Schema primitive data types is pretty good, and that either other types could be coerced to them or we'll make do with strings as we have in XPath 1.0. So I think it would also handy to be able to get quick access from an element or attribute to the name of its type, and to its value as the appropriate XPath-supported data type. ... Well, those are some ideas anyway - I'm not sure whether they tie together or would stand up to close scrutiny. I'm almost certain that it isn't the way that XPath will be developed :) Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|