[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: How to spell "No PSVI" in XSLT 2.0 without getting sucked
Uche (and Jeni), Let me modify the wording of the two XSLT 1.0 data model characteristics I tried to identify. First, 1. There was always an unambiguous, lossless, mapping between the data model and its serialized form, and (Yes, after c14n its one-to-one, but that's the whole point of c14n; it was misleading for me to say "one-to-one" here.) The real point I was trying to make is that the XSLT 1.0 data model can be reliably round-tripped between tree-building, serialization, parsing, and tree-building. Moreover, the data model is closed--any output can serve as input. The domain and range are the same set (this is a one-to-one mapping except for the inability to construct IDs in the result tree, arguably a flaw of the language rather than the data model). The XPath 2.0 data model, on the other hand, has to decide how to serialize elements with typed values, parentless attributes, etc. The set of possible data model values extends beyond what we already know how to serialize. Second, 2. all information in the data model can be present in the corresponding serialized *instance* document. The point I was trying to make here is that there is nothing in the XSLT 1.0 data model that can't be serialized in the instance document (even ID declarations). The XPath 2.0 data model, on the other hand, is based on the PSVI which results from an external schema being applied to the instance. Serialization was a top priority in the design of the XPath/XSLT 1.0 data model. Serialization has been an afterthought in the XPath 2.0 data model. (How do you serialize a typed node? Do you construct a schema on the fly? Where do you put it?) I'm saying that it's okay that XSLT 1.0 doesn't require xsl:output, etc., and it's only okay because its data model is bound so tightly to a corresponding serialization. This means that conformance tests are possible by assuming a straightforward tree-building and serialization. Requiring conformance only to tree transformations (while ensuring that trees have an obvious serialization) and allowing limited optional serialization features for convenience has been a largely successful balancing act. Adding something like xsl:input tips the scales toward stylesheet writers tending to depend more heavily on optional features, and that scares me. In any case, my point isn't to say that xsl:input as you conceive it is bad, but rather that it doesn't solve the problem I'm trying to solve! > OK. I really think we've got hold of a misunderstanding here. Yes we do :) > No one is saying xsl:input shouldn't be optional. I understand that xsl:input as you conceive it would be an optional feature. But my point is precisely that an *optional* feature won't help. > If you consider "M$tripping-whitespace" an "abuse", then you > might expect *much* worse from XPath/XSLT 2.0 implementations, so > I would expect you to be eager to patch up the hole. You can't patch up the hole with an optional feature. The hole would still be there. I think we're trying to patch different holes :-) Really, we're trying to define what we each think a "No PSVI" XSLT 2.0 would look like. I'm not satisfied with your approach because it doesn't allow the stylesheet writer to *ensure* that input will be plain vanilla XML. The XSLT processor or framework will always have the option of ignoring your xsl:input directives. That said, xsl:input may be a good idea in itself. I just think that it is *insufficient* to safely insulate stylesheet writers from the PSVI. > > In > > particular, the stylesheet writer should have a way to switch > between plain > > vanilla XML/Infoset, and PSVI with PSVI-specific information items. In > > short, this is a data model issue more than a processing model issue. > > I'm not sure you can separate the two. I predict that if you > come up with a way to spell it as a data model rather than > processing model issue, you'll end up with precisely the same > function and implementation. Not at all. I'm saying that a document can have been schema-validated but still only look to a stylesheet writer like elements, attributes, and text. This has nothing to do with an xsl:input or any other kind of parse directive. It's a *required* flag that can be used to restrict the *data model*, rather than an optional one to restrict the processing model. However that would ultimately be specified, I don't particularly care--as long as the stylesheet writer has a way to enforce that all of its operations will behave on a tree of elements, attributes, and text the same way, regardless of the processing history that generated that tree. Evan
|
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
|