W3C home > Mailing lists > Public > www-tag@w3.org > June 2002

RE: Potential new issue: PSVI considered harmful

From: Dare Obasanjo <dareo@microsoft.com>
Date: Wed, 12 Jun 2002 14:04:36 -0700
Message-ID: <8BD7226E07DDFF49AF5EF4030ACE0B7E06621CDB@red-msg-06.redmond.corp.microsoft.com>
To: "Simon St.Laurent" <simonstl@simonstl.com>, <www-tag@w3.org>

-----Original Message----- 
From: Simon St.Laurent [mailto:simonstl@simonstl.com] 
Sent: Wed 6/12/2002 1:03 PM 
To: www-tag@w3.org 
Cc: 
Subject: RE: Potential new issue: PSVI considered harmful

At 12:42 PM 6/12/2002 -0700, Dare Obasanjo wrote:

>>  most of it boiled down to what seemed primarily to be personal dislike

>Personal dislike?  That seems like you've chosen the wrong (and
>unnecessarily derogatory) adjective.  It seems to be the case that people
>dislike W3C XML Schema (or like it) for various technical and sometimes
>business reasons. (See [s2].)

I read your article at [s2]. 
 
You link to Tom Gaven's article where he complains about the following features of W3C XML Schema; verbosity, derivation rules and size of the spec. I agree with him about the verbosity of W3C XML Schema and that the size of the spec is relatively large but disagree with some of the technical points he raised on type derivation. Instead of going of on a lengthy tangent I'll just point out that substitution groups can be used to gain the benefits of polymorphism without the usage of xsi:type. Also emptiable particles do not have to be repeated in the content model of derived type definition. 
 
You also link to James Clark's mail to the ietf-xml-use alias where he challenges their recommendation of W3C XML Schema. I refuted about two of his points on XML-DEV. The rest are mostly valid criticisms of W3C XML Schemas inability to describe complex co-occurence constraints and the fact that the W3C XML Schema Structures recommendation is written in an inaccessible manner. 
 
The rest of your links reiterate the points in the first set of links. In short, most of the complaints circle around the difficulty of the spec to read and an inability to express more complex constraints. 
 
Now having summarized the series of links in your article I still see nothing which points to a coherent argument against XQuery and XPath 2.0 supporting W3C XML Schema for use in type aware queries. Especially since nothing in either recommendation mandates the usage of W3C XML Schema. 

>>  of W3C XML Schema and worries of implementation complexity.

>"Worries" is again an odd word.  It's very clear - indeed, from some of
>your own recent posts on xml-dev - that W3C XML Schema is very difficult to
>implement correctly.
 
Agreed. The spec is primarily difficult to implement because of the inaccessibility of its main documentation to the average developer. This however is not an insurmountable problem. 

>>  Now given that one of the major concerns was XPath 2.0 which allows
>> implementers to use both a flexible type exception policy with fallback
>> rules[1] as well as the consideration that static typing may be optional,
>> it seems that some of the fears in the 150 - 200 posts about XPath 2.0,
>> XQuery and the PSVI may have been allayed.

>If this means that schema processing is no longer required for XPath and
>XQuery, then you may have achieved a weak version (the first part) of what
>Tim was asking for in the first place:
 
Currently XQuery has constructs for importing schemas but XPath 2.0 does not. I don't think the situation will be changing for either case anytime soon. 

TB> 4. Work on XQuery and other things that require a Type-Augmented Infoset
TB> must not depend on schema processing, and should not have normative
TB> linkages to any schema language specifications.

>I could tolerate optional static typing provided that the specification
>provided a conformance level for implementations which simply do not
>perform static typing, schema or no schema.
 
I assumed this was what the REC would eventually allow but you can ask on the XML Query comments list for clarification. 
Received on Wednesday, 12 June 2002 17:05:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:08 GMT