Re: Unserializable documents

On 9/5/07, Norman Walsh <ndw@nwalsh.com> wrote:
> / Alessandro Vernet <avernet@orbeon.com> was heard to say:
> | The way I read this, this implies that an implementation is fine using
> | SAX (or SAX++ to handle sequences) between components, without adding
> | a whole lot of necessary processing of those SAX events between steps.
> | So this is good.
>
> Yes.
>
> | But shouldn't we specify what we mean by "namespace fixup" (maybe a
> | reference to the XSLT specification?) and "other necessary
> | adjustments"?
>
> On reflection, I think namespace fixup is *all* we mean. I'll steal a
> defn from XSLT, I think.

I agree.

I just went through the serialization specification, XSLT 1.0, and XSLT 2.0 and
I think we have a problem here in that:

  * we reference the serialization specification and it does not define
     or use "namespace fixup"

  * XSLT 2.0 says that namespace fixup happens when the literal
    elements are created.  As such, the output of an XSLT 2.0 processor
    will not need namespace fixup.

  * XSLT 1.0 says namespace fixup happens at serialization.  It really
    doesn't define that except to say (section 16.1):

     "The new tree may contain namespace nodes that were not
      present in the result tree."

As such, we'll need to define what we mean by "namespace fixup" and,
with the wording suggested by Norm, realize that valid XSLT 1.0
transformations could fail in some xproc implementations if they
choose to fail on undeclared namespaces.

One possible solution is to say that we require namespace fixup on
the output of the XSLT 1.0 step.

In fact, I'd like to go through all our steps and guarantee that we do the
right thing with namespace declarations.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Wednesday, 5 September 2007 14:03:31 UTC