[
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.
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
2. with few exceptions, all information in the
data model was present in the corresponding
serialized *instance* document.
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.
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.
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.
Such a flag would enable a stylesheet to process an XML document as vanilla
XML, regardless of its processing history. Its processing history may or may
not include XML Schema validation. In the event that it does, the visible
PSVI augmentations will be constrained to the kinds of information that can
occur in the restricted, vanilla data model, namely defaulted attributes,
etc. This implies a straightforward algorithm for interpreting a PSVI as an
augmented Infoset without the PSVI-specific information items. Such an
algorithm would be akin to taking the PSVI, serializing the instance, and
parsing it again without respect to a schema.
I think this is an approach that should be discussed, including possibly the
syntax for such a flag and whether it branches out into directives for
interpreting input with respect to particular schemas, etc.
Evan
(henceforth and as always speaking for himself only, blah, blah)
|
