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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] RE: PSVI and XPath 2.0 data model

[ Lists Home | Date Index | Thread Index ]

At 1:39 PM +0000 5/8/02, jborden@attbi.com wrote:

>I think what this means in practice is that the Infoset
>for better or worse is the only reasonable "standard mapping"
>of an XML document to a tree. XSDL does define a specific
>transform between an Infoset and a "PSVI"  and XSLT 2.0 takes
>such a "PSVI" as an input -- so far so good. Do you really
>want to _limit us_ to using XSDL as the only mechanism of
>specifying a "PSVI" i.e. suppose someone writes a perfectly
>good RELAXNG processor that emits a "PSVI", are you saying
>that you want to disallow this?

No, I don't want to disallow that. Chaining processes should be 
allowed. However, I do want to disallow an XSLT processor from only 
operating on the output from such a process, and I want to disallow 
it from automatically feeding a genuine XML document into such a 
process as part of the source tree construction. If the user chooses 
to give the processor, a RELAX NG PSVI as input that's OK. However, 
the XSLT processor should not apply a RELAX NG process before 
transformation unless the user has asked it to do that.

For my purposes I'm more concerned with what happens in well-formed 
XML documents without a schema. If that behavior is well-defined, 
then processors are testable and statements like "Processor X adheres 
to the XSLT 2.0 specification" and "Processor Y does not conform to 
the XSLT 2.0 specification" have meaning.

Schemas do confuse the picture. For that matter, so do DTDs though at 
least the XSLT 1.0 specification is clear on how they do. (i.e. you 
must use a parser that reads the full DTD and resolves external 
entity references.) Now if I had my way, I'd throw schemas and types 
out of XSLT2/XPath2 completely; but facing facts given the  culture 
and structure of the W3C that's not going to happen no matter how 
good an idea it is. So given that we have a less than optimal, very 
messy, non-layered solution that does involve schemas, how can we 
work around the problems this introduces?

I suspect something similar is needed to how DTDs and their messy 
interaction with the data model is handled in XSLT 1.0. An XSLT 2.0 
processor which encounters a document that uses xsi:schemaLocation 
and xsi:noNamespaceSchemaLocation attributes must apply the relevant 
schema before processing. That is, it must use the schema to insert 
default attribute values and default elements. In the event of a 
conflict between the schema and the DTD, pick one in the spec. I 
don't really care which as long as it's consistent. (That's an edge 
case anyway.) If the schema reference is not available or is 
syntactically incorrect, then the transform should fail, just as it 
does today when the DTD is not available.

An XSLT 2.0 processor which encounters a document that does not use 
xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes must 
not apply any schemas.

Processors may (but are not required to) giver users/developers an 
option to change the above behaviors. For instance, an API call could 
be made to say "Use this schema" or "don't use any schema at all" 
However, the default behavior absent explicit requests otherwise must 
be as described above.

OK. That covers the W3C XML Schema Language. What about others? We 
should handle them similarly with one key difference. Processors may 
choose to support the application of a RELAX NG or other schema 
language schema to the document, along with appropriate application 
of default values, types, and similar things. However, this ability 
must be turned off by default, and should be turned on only at 
explicit user request. Of course you could use this strategy for the 
W3C XML Schema Language too, if you prefer. That's more consistent 
and more fair, but I suspect those users who use W3C schemas would 
prefer to have schema parsing be the default.

| Elliotte Rusty Harold | elharo@metalab.unc.edu | Writer/Programmer |
|          The XML Bible, 2nd Edition (Hungry Minds, 2001)           |
|             http://www.cafeconleche.org/books/bible2/              |
|   http://www.amazon.com/exec/obidos/ISBN=0764547607/cafeaulaitA/   |
|  Read Cafe au Lait for Java News:  http://www.cafeaulait.org/      |
|  Read Cafe con Leche for XML News: http://www.cafeconleche.org/    |


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS