[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RE: PSVI and XPath 2.0 data model
At 1:39 PM +0000 5/8/02, jborden@a... 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@m... | 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/ | +----------------------------------+---------------------------------+
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|