Re: [xml-dev] RE: Namespaces Best Practice

[Tony.Coates@reuters.com]

On 21/09/2001 10:18:25 PaulT wrote:

>----- Original Message -----
>From: "David Carlisle" <davidc@nag.co.uk>
>
>> XSLT processors normally need to process entire input documents but XSLT
>> is designed so the result can be streamed.
>
>Really? Is there any W3C document that says it?
>Sofar I have not seen a single XSLT engine
>not accumulating the output... What is 'normally',
>by the way?

I won't go into what may or may not be "normal", but XSLT is certainly *designed* to be streamable.  I found recently that one popular XSLT processor tends to put all namespace declarations at the top of the output, while another popular processor puts them as far down the tree as possible.  In asking various XSLT luminaries about this, I was told that the XSLT spec is likely to tighten up to stop processors from trying to put all namespace declarations at the top.  There are two reasons for this.  One is for performance, as mentioned in a previous post.  The other is that namespace prefixes are allowed to be re-used in different parts of a document for different namespaces, and XSLT is sensitive to the prefix as well as the namespace, so there is no (simple) general mechanism by which you actually can move all namespace declarations to the top in all possible cases.

Of course, you can argue that it might be poor practice to re-use namespace prefixes in this way, but XSLT processor authors shouldn't be asked to get into the business of only supporting those documents that they consider exemplars of "good practice".  Also, in certain enterprise workflows, where content is pulled from different places and combined, there may be good reasons for wanting to re-use namespace prefixes, on the understanding that you have to be careful when you do this.

     Cheers,
          Tony.
========
Anthony B. Coates
(1) Content Distribution Architect - Project Gazelle
(2) Leader of XML Architecture & Design - Chief Technology Office
Reuters Plc, London.
Tony.Coates@reuters.com
========



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.