RE: Crazy idea
I like the idea very much, have you tried it on a lot of examples ? Is it hard to generate (automatically) an XSLT stylesheet for a given XSchema ? It's a good oportunity for reuse (of code and architecture) It seems that XSLT has more uses other than for what it's designers had in mind, for example I use it for XML to Object mapping, I have a big and complex tree of objects, I persist it by writing it's XML representation in a file, (that's the easy part), the hard part (from XML to Objects) I use XT, (but any XSLT processor that can take objects as parameters would do). Of course I only use XPath and java extensions (I don't produce any result tree), so a stand alone java implementation of XPath would be just as good. > Mulling over the namespace/XSchema issue, I came up with the following > notion. I wonder if it has ever been suggested, and what its chances are. > > A DTD/XSchema, as defined today, performs two tasks. One is to validate a > document. The output of this is a single Boolean value. The other is to > "complete" the document - that is, add defaults. > > The latter part seems like a transformation task to me, which raises the > question: why not specify this as an XSLT stylesheet? Once you consider > this, it becomes obvious that the first part can also be specified as a > stylesheet, given that one introduces some way for a stylesheet > to indicate > an error in the input (say, <xsl:error>). Actually, that's a good idea by > itself. I already simulate it in my stylesheets by emitting an obtrusive > error boilerplate, but that's a kludge. > > Objections: > > - You need an XSLT processor instead of just an XSchema processor. > > Given that an XML system is likely to have an XSLT processor anyway, this > might be viewed as removing a component instead of adding one. > > - Doing full XSLT processing is more expensive then "just" XSchema > processing. > > Is it? The XSchema spec is already quite complex, what with schemas > importing one another and so on. There's also the issue that if > we'd be only > using XSLT, then the effort that would have gone for writing XSchema > processors would go instead for optimizing XSLT. > > - XSLT is be "too strong". After all, it is Turing complete. > > XSchemas are already stronger then DTDs, for a good reason, so > this might be > an advantage. Otherwise, it might be useful to define a subset of XSLT to > use in "schema" stylesheets. > > - People would abuse it. > > That is, people would create "schema" sheets which would transform the > document to something completely different then what you started > with. There > are several answers to this, ranging from "so what? anything good can be > abused" to "define a strict subset of XSLT which can't be abused". My > suggested compromise is to require that a "Schema" XSLT stylesheet should > only emit "fixpoint" documents - that is, applying it a second > time must be > a no-op. This is trivially testable and satisfies most objections > as to the > difference between "validation/completion" and "transformation". > > - The XSchema WG would be out of job :-) > > Someone should consider what modifications, if any, are required for using > XSLT in this capacity. We'd need <xsl:error> or something equivalent (a > construct which is useful in general). There might be a need to pick a > subset of XSLT. There may be other issues. The whole concept of using XSLT > for validation would justify a separate spec. So the Schema WG would > actually be quite busy formulating it. > > The benefits are obvious: > > - KISS. > > Just one spec, instead of two; just one implementation, instead of two. In > fact, I'd consider this an overriding consideration. The burden of proof > should be on the other side to justify the need for a separate spec :-) > > - Time to recommendation. > > The recommendation could be released very soon after the XSLT one. That > should be much faster then the current expected time for XSchema > to finalize > (I think). This can be done since A lot of sticky issues in the > XSchema spec > are automatically resolved. How to reuse XSchema "modules"; specifying > intelligent defaults; mixing namespaces within a document; etc. > > - Time to implementation. > > We get a strong, flexible, powerful schema mechanism with robust > implementations, immediately. I don't doubt the ability of the > XSchema WG to > come up with a good recommendation, but how long would it take > until we see > it implemented properly? > > - Market acceptance. > > By tying schemas to XSLT, every time a company uses one, it automatically > can make use of the other. This would increase the market penetration of > both recommendations. The schema recommendation stands to make most of the > advantage; given that XSLT processors would be available in browsers and > servers as a matter of course, this would significantly lower the barrier > for performing validation, as compared to obtaining a separate schema > processor > > How about it? > > Oren Ben-Kiki > > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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