Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath 1.5? (was RE: typing and markup)
 > In general, I suspect that a query language that is integrated with the > type system of XML Schema is a significant simplification for the user, not > a complication, because it allows the XML to be processed directly, and > does not require mapping to other type systems before processing can occur. > The user does not have to figure out how dates should be sorted or how they > map to a particular implementation's date type, the user simply does > queries on dates, and they act like the user expects them to. > > Jonathan Having a richer set of base types for dates etc is on the whole a good thing, and given that it's a W3C spec it's inevitable that W3C schema versions of those types will be used. But the association between element names and types of their content could be in the stylesheet/query language rather than the schema, You don't need to assume a PSVI input to provide functions that can sort dates. Xpath2 is dangerously tied to XML schema whereas it could be far more neutral in its support of schema languages: dtd, w3c schema, relaxng, ... In an Xpath/XSLT setting (if not XML Query) the support for schema complex types vastly complicates the specification for very small benefit and doesn't address any issue with Xpath/XSLT that has been raised on any XSLT forum that I've seen over the last couple of years. Lots of people have posed problems that would naturally require higher order functions or dynamic evaluation of XPath for example (neither of which feature is being added) but no one has ever asked to address elements by specifying their content model (in either DTD or schema syntax) rather than their name. If I want to find all elements called foo with an X attribute it is far more natural in Xpath to ask for foo[@X] rather than define that type in XML schema, tie myself to an XML parser supporting XML schema and upgrade to an XSLT/XPath2 system and then query the element via its schema type. Adding dates and regexp from schema to Xpath is strengthening Xpath in areas where it is weak. Adding a new method of describing element structure is just making the language horribly complicated for little to no benefit. (The optimisation arguments are far less convincing for XSLT than they are for Xquery, as the usual model is that each document is parsed afresh each time rather than working over some persistent set of data matching a fixed schema. The idea that a query system can optimise away, or generate errors on, queries like aaa/bbb if the schema specifies that aaa has no bbb children is also very worrying. How could one write schematron in Xpath2 if it needs to find exactly such cases and report errors? Xpath1 was designed to work on documents that specified a DTD but were invalid, not only well formed documents that did not specify a DTD. Is the same really true of Xpath2 wrt schema? David _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. 
|
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
|
|||||||||
