OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more grist



From: Henry S. Thompson <ht@cogsci.ed.ac.uk>

>Eric van der Vlist <vdv@dyomedea.com> writes:

>> The way I read Simon's article (and the position I defend), it's not a
>> criticism of W3C XML Schema, but the fact that other applications will
>> become dependent on W3C XML Schema.
>
>In so far as they do, it's because they have requirements that can
>best be satisfied that way.  The alternative (e.g. for XML Query and
>XML Protocols) would be to define their own, incompatible with XML
>Schema or each other, type system.  Surely _that_ would be a step
>backward.

But presumably the problem is that existing specs will be discontinued in
favour of the schema-aware versions. So users who do not find a type system
or XML Schema's particular feature mix to be appropriate (for example, some
eccentrics may think that markup requiring type from a PSVI is clunky when
they could achieve much the same effect by keeping the (e.g., abstract) type
name as the generic identifier and using some attribute to record the
"derived" type in use: this might have desirable effects in a similar case
to when IDs are valuable even for data---when your consumer is too
lightweight to handle various kinds of key mechanisms.

For those kinds of users, schema-processing is an unnecessary task; for
lightweight systems any unnnecessary task is a burden. I don't see why such
people would rejoice at the prospect of the W3C specs which are currently
useful for them being discontinued for the schema-aware versions.

The solution seems straight-forward to me. It is not to ban XML Schemas or
Specs based on it.  It is to continue to develop in parallel the existing
non-schema specs until the XML Schemas technology has proved itself to be
light-weight-implementable and useful.  So all the non-PSVI innovations in
XPath2 should first be incorporated into XPath 1.2.  And all the non XPath 2
innovations for XSLT 2 should first be incorporated into XSLT 1.2.

I don't think anyone sees PSVI-based systems as being ready this year: I
think we still are on the requirements phases only.  So I think there is
real utility in maintaining the non-PSVI specifications for at least another
year or two. In any case, a PSVI implementation can have a switch to turn
off PSVI features, so it would not lead to any more split in features and
availability than we will have anyway with XSLT 1 and XSLT 2.

Obviously, I am in the camp of people who would prefer explicit markup in
interchanged documents, seeing a schema as a way to guarantee that certain
data structures are in place (or banned) to simplify the programmers' task,
rather than seeing a schema as something which needs to accompany the
document and guide its interpretation, though both have their place.

Cheers
Rick Jelliffe