Subject: Re: [xsl] James Clark on Schema From: David Carlisle <davidc@xxxxxxxxx> Date: Wed, 5 Jun 2002 14:03:11 +0100 |
Mike> Unfortunately those AC reps are the same people who voted to make XML Mike> Schema a rec Not necessarily. Turnout is all important, it might be that all that's needed is to awaken the silent majority.... But it would be better to persuade the working groups to modify things of their own accord rather than hit them with the blunt instrument of W3C process. Mike> I wish XML Schema would go away (I still wish namespaces would go Mike> away...) but it won't. There is a real difference between recognising the fact of W3C Schema and accommodating its use (which is how I read the requirements document when it came out) and so closely tying XPath to W3C Schema typing semantics that it is in gave danger of causing the future one of W3C's most successful specifications to be irretrievably doomed to follow the same course as W3C Schema, on which the jury is still most definitely out (MS implementations not withstanding). There did_ need to be a defined mapping between schema types and XPath types, but that isn't what XPath has done, it has just adopted W3C Schema wholesale. XPath needed functions that operate on dates, but does it really need all of the following types? xs:duration, xs:dateTime, xs:time, xs:date, xs:gYearMonth, xs:gYear, xs:gMonthDay, xs:gDay, xs:gMonth and the mess of casting and conversion functions that are the result of this ad hoc collection. The same is true of Constructor Meaning xf:string Produces a string value by parsing and interpreting a supplied string. xf:normalizedString Produces a normalizedString ? the XML Schema datatype ? value by parsing and interpreting a string xf:token Produces a token value by parsing and interpreting a string. xf:language Produces a language value by parsing and interpreting a string. xf:Name Produces a Name value by parsing and interpreting a string. xf:NMTOKEN Produces an NMTOKEN value by parsing and interpreting a string. xf:NCName Produces an NCName value by parsing and interpreting a string. xf:ID Produces an ID value by parsing and interpreting a string. xf:IDREF Produces an IDREF value by parsing and interpreting a string. xf:ENTITY Except for the first (which is in XPath 1) I'd say the presence of all these functions is providing little to no useful functionality and is doing real damage to the usability of XPath as a language. and these are not much better (except for the first two) xf:decimal xf:integer xf:long xf:int xf:short xf:byte xf:float xf:double XPath already has (is, in fact) a mechanism for describing the structured content of an XML element. Its type system does require extending to better describe the data values, but it should be designed with a simple coherent set of types (XPath 1 + something for dates + perhaps integer + perhaps URIs and Qnames) that can be mapped from a range of schema languages. As things stand now, if I had a vote (which I don't) given the current suite of documents I'd vote yes to XSLT2 and no to the rest. there is some good stuff burried in XPath2 but it is buried so deeply it is hard to spot. On the other hand XSLT2 (Grouping, multiple output, no rtf, user defined functions) running over XPath 1 would answer a large number of the user problems that come up on this list. 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. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] James Clark on Schema, Francis Norton | Thread | RE: [xsl] James Clark on Schema, TSchutzerWeissmann |
Re: [xsl] James Clark on Schema, Francis Norton | Date | Re: [xsl] What is %26 doing in my H, Zack Brown |
Month |