[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
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)
|
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
|