[
Lists Home |
Date Index |
Thread Index
]
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
|
