Subject: Re: result-ns (was RE: XSLT vs JSP) From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx> Date: Mon, 28 Jun 1999 17:11:23 +0200 |
Simon St.Laurent <simonstl@xxxxxxxxxxxx> wrote: >Yikes. I still can't understand why anyone considers result-ns a good way >to indicate what the result syntax should be, This is a way to work around XML syntax limitations without having to extend XSLT in any way. For example, it allows an XSLT processor to support CDATA output elements such as SCRIPT for HTML, even though they are illegal in XML. If/when a new output syntax comes along which is vaguely hierarchical, this mechanism would allow supporting it by specifying the appropriate namespace - without any change at all to the XSLT specs. The alternative would have been to extend XSLT to explicitly support non-XML constructs (such as CDATA), which some people feel very strongly about. Using namespaces is a very elegant way to avoid this problem - even though it is a hack. Another point is that you would give up on ensuring the validity of the structure of the resulting document. This already happens when, for example, generating embedded JavaScript code in HTML documents - there's no way to be certain that each '{' has a matching '}'. I've been bitten by that quite a bit, actually. If I was able to specify <js:block>...</js:block>, <js:string>...</js:string> (which would have handled quoting for me) etc., then generating such code would have been easier. Of course, how to mix several output namespaces is not exactly clear at the moment... >leaving it up to every XSL >processor to keep a list of namespaces and provide code for supporting them. That's the down side of this hack. The spec defines very few standard namespaces, which means that generating XML or HTML is OK and anything else is processor dependent. James Clark has implemented in XT a namespace for generating arbitrary output text. I'd really like to see it (or something like it) make its way to the specs, since it is a very useful "safety valve" - with some effort one can generate anything at all using it. >Maybe if there was a pluggable module for handling result-ns, or, better, a >vocabulary developers could use to describe to the result syntax that was >somehow referenced by the XSL style sheet, this approach could work >smoothly. Right now it feels like a random bit hanging off the side of the >spec. Maybe it's just an escape clause, but I can't say it feels like a >'real' solution - that's probably why it's described as a 'hint' in Section 5. What you describe already exists :-) Simply emit the document in standard XML syntax, then feed it into another XSLT pass, using a stylesheet describing the output syntax, and whose output is in James Clark's any-possible-text namespace. Problem solved. If there was an easy/standard way to specify that an XML document has to go through a _chain_ of stylesheets, the above would become trivial and probably be the recommended way to add new syntax forms (instead of adding magical namespaces). By providing a stylesheet one would know the new syntax would work with any XSLT processor. That's why something James Clark's any-possible-text namespace should be part of the specs. There are other advantages to this approach. For example, it would remove the need to be able to match on result tree fragments. Instead processing would be broken to explicit stages. If each stage is "incremental", then the chain would also be. Debugging such a chain would be easier then debugging a monolithing stylesheet. Another bonus is the ability to develop reusable XSLT components. Have fun, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Exit in XSLT: was jumps (gotos....), Smith, Brian BC | Thread | RE: result-ns (was RE: XSLT vs JSP), Mike Brown |
Re: New XSL Optimization, Paul Prescod | Date | RE: result-ns (was RE: XSLT vs JSP), Mike Brown |
Month |