RE: James Clark on Schema
>> * It is unreasonable to expect a W3C specification (such as XQuery) to >> adopt as its basis a data model not under control of the W3C, when there >>is >> a W3C data model that is acceptable. >> ... >> To hope that the various Working Groups will "see >> the light" and choose to use a schema-like facility defined outside the >>W3C >> is highly unlikely. It might be unlikely but there a number of different xml-based schema languages out there, as these are also based on W3C standards - such as xml :) - I can't help but think that to build one's own schema language, that most of the people familiar with other W3C standards seem to actively dislike, and then to start requiring other popular standards support their ugly cousin is a recipe for driving us all to Perl and regular expressions(and I hate Perl). If a prior standard should be made to support validation methodologies then it should do it at a far higher level of abstraction, this is to say that just as there was an xml infoset there should be a schema infoset, and I think the rule should be the schema infoset could not be any longer than the xml, so as to prevent another evil monster Spec from developing and terrorizing humanity. When I say the above about schema infoset I am partially facetious, but I have argued to no great success in the past for being able to query against some sort of abstract validator, and the specific validator be defined by implementor, and I still think this would be preferable for me at least, and as I consider myself a representative, average developer I suppose it would be preferable to the community. This might not be as extremely useful as being able to query against all the possible datatypes and what-not that an xml-schema specific requirement would allow, but I doubt it would be as deadly either. David Carlisle wrote: >I have never argued that XPath2 should be based on Relax NG, what I have >argued is that it shouldn't be based so closely on W3C Schema. In >particular, concentrating for now on the simple types rather than >complex types (element structure) it should not have accumulated >the mass of numeric, date and string types. They make no sense to be >hardwired into a query language aimed at generic XML documents. >No fixed set of random types will ever be of any real use in an XML >context as most of the documents are generated for reasons unconnected >with XQuery/XPath. An XML Query language has to be able to cope with >whatever's out there it can't just invent a world view and pretend that >all documents will conform. Having a float and an integer type (already >an extension to XPath 1) makes sense; having byte and friends is just >slavish devotion to the schema spec. Dropping them does not mean >abandoning W3C and following James into the uncharted waters of ISO. It >just means making XPath usable again. A small section of a revised >XPath2 document mapping the primitive W3C schema types into XPath would >be all that's required. Okay how about this: Oasis donates RELAX NG to the W3C, they immediately rename it Xml Schema 2.0(either that or Topologi donates schematron, that's what I want) :) and start working on Xml Schema 3, in this way they could act as though they haven't lost the hearts and minds of the community and declare marketing victory. Then again maybe they create an xml schemas working group which realizes the need for various schema languages and start marketing Xml Schema as one especially suited to the needs of ... - ? >If you want an integer less than 0 and 2^8 you should be able to >express that in the same way as an integer between 0 and 12, >why have a special "byte type". At first sight it doesn't appear too bad, >as if you don't need it don't use it and if you do need it it might save >a keystroke or two, but the net effect of having dozens of pointless >primitive types in the language is that the language has an exponential >explosion in the complexity of its casting rules and functions, and is >impossible to learn: I challenge anyone to list the full set of primitive >XPath2 types off the top of their head, without reference to the spec >(F&O or schema). Yeah and what if someone has learned something different than you. What if you come from a language where some of these types don't exist and someone else comes from a language where they do. What's the chance that their xslt 2.0 will depend on datatypes similar to ones they are used to analyzing? Pretty high I bet. >Support for complex types also massively complicates the specification >for little to no benefit. If you want to find all children elements that >have a parent parent, it is far more natural to use XPath parent/child I >see no occasions when it would be more natural (In an Xpath context) to >define a schema type for that construct and and then query on the >type. This comment is not particularly against W3C Schema it is a >comment on Schema in general with respect to XPath. (Schema are fine for >their main use of constraining authoring and checking that a document is >correctly authored. But querying is something different) >A schema type is basically just a named content model in a DTD (if you >view DTDs as a schema language with non-XML syntax) As far as I can >tell no one ever asked in an XPath or XSLT context to be able to query >by a particular content model without having to specify the element >name When is this supposed to be useful? (None of the XQuery use cases >show any use for this facility other than in the case of generic computational stylesheets I can think of none, and as computational stylesheets are a small subset of the whole production of stylesheets worldwide I assume it would be better to leave it out. At any rate computations of any worth would probably be suited to a particular content model. 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