Re: [xsl] James Clark on Schema

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