[
Lists Home |
Date Index |
Thread Index
]
> Jeni, Uche,
>
> As much as I resonate with the intent of your approach, I think it's the
> wrong one. While there are examples of abuse (e.g. M$tripping-whitespace),
> XSLT 1.0's deliberate de-coupling of data model and serialization was a good
> and successful decision. xsl:output is an optional feature for very good
> reasons. This design has made for a remarkable marriage of flexibility and
> interoperability.
OK. I really think we've got hold of a misunderstanding here. No one is saying xsl:input shouldn't be optional.
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.
I agree with Elliotte that we should clarify the specs in this regard. I don't agree with the wording he suggests: which reads to me (perhaps unfairly) as a post-facto way to win an argument. Instead, I think we should recognize that people should have a choice on matters such as whitespace, XInclude, XML Base, etc., and we should provide facilities for allowing them to be clear on such issues until we have standard pipelining systems we can use instead.
> As far as I see it, there are two things that were *crucial* in ensuring the
> success of this approach:
>
> 1. There was always an unambiguous, lossless,
> one-to-one mapping between the data model
> and its serialized form, and
Not even close. I must be misunderstanding you here. Just to pick one of a million things that make it ambiguous: one processor can choose to put out character entities in a case where another puts out the character "directly". One can use single quotes and another double quotes.
Do you mean unambiguous after c14n? Even if I assume so, I think (though I'll admit to not being sure) that there are a couple of loopholes in namespace node copying that can make a difference post c14n.
> 2. with few exceptions, all information in the
> data model was present in the corresponding
> serialized *instance* document.
Hmm. "a few examples" stretches pretty far. Defaulted attributes and unparsed entities in the external subset, and all that.
> The PSVI is the antithesis to both of the above. And this is why many of us
> are worried about how interoperable our stylesheets will be in a
> PSVI-oriented world.
I do agree that the PSVI tends to magnify the problems to no end. It will turn what are little annoyances into full-scale interoperability problems.
> However, I don't think we can dictate a processing chain from the stylesheet
> any more than we could before. Even if we tried, this won't buy us
> interoperability, given the many processing frameworks that aren't
> controlled by "XSLT applications" but nevertheless use XSLT processors. If
> anything, such an attempt will complicate interoperability problems in the
> same way that xsl:disable-output-escaping does today.
Wow. What we're proposing is parsecs from xsl:disable-output-escaping, don't you think?
In my original proposal, which I now think of in terms of xsl:input, I illustrated 3 stipulations
1) To PSVI or not to PSVI
I get the sense we can all agree on this
2) To XInclude or not to XInclude
The ongoing debate shows there are already interop problems and I'm not sure how being more specific could make it worse
3) Reference to an *external* pipeline definition
Which is almost as if I read your mind seeing what reservations you'd have :-)
I'm not sure why there is a problem.
> Rather, what is needed is a way to dictate what *kinds* of information can
> be present in a source/result tree, based on some flag in the stylesheet. 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.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
The Languages of the Semantic Web - http://www.newarchitectmag.com/documents/s=2453/new1020218556549/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
|
