W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > September 2007

Re: Towards a consensus draft (urgent)

From: Norman Walsh <ndw@nwalsh.com>
Date: Mon, 10 Sep 2007 15:53:22 -0400
To: public-xml-processing-model-wg@w3.org
Message-ID: <m2ir6ixpot.fsf@nwalsh.com>
/ Alex Milowski <alex@milowski.org> was heard to say:
| On 9/10/07, Norman Walsh <ndw@nwalsh.com> wrote:
|> / Alex Milowski <alex@milowski.org> was heard to say:
|> | On 9/10/07, Norman Walsh <ndw@nwalsh.com> wrote:
|> |> Dear Working Group,
|> |>
|> |> Please review the latest editor's draft (or at least sections 2.2 and
|> |> the new 2.6.1, as well as p:label-elements) and *if you do not believe
|> |> that we can go to Last Call with this draft* please *comment in email*
|> |> as soon as possible.
|> |
|> | None of my proposal on having the steps "do the right thing" is in
|> | this draft.  If
|> | we can't (or don't want) to mandate that steps do the right thing, at least we
|> | should add them as "should/may" or example of avoiding namespace
|> | fixup.
|> The whole point of 2.6.1 is to say globally, in one place, that all
|> relevant fixup may be performed between each step and must be
|> performed when documents are serialized.
|> I think that all of the specific changes that you proposed for individual
|> steps are covered by the statements now present in 2.6.1:
|>    ...In particular, the information corresponding to the [Infoset]
|>    properties [attributes], [base URI], [children], [local name],
|>    [namespace name], [normalized value], [owner], and [parent] *must* be
|>    preserved.
|>    The information corresponding to [prefix], [in-scope namespaces],
|>    [namespace attributes], and [attribute type] *should* be preserved,
|>    with changes to the first three only as required for namespace
|>    fixup. In particular, processors are encouraged to take account of
|>    prefix information in creating new namespace bindings, to minimize
|>    negative impact on prefixed names in content.
| They aren't completely covered.  In some cases you (unwrap & rename),
| you want to "push down" the in-scope namespace to preserve for the children
| elements.   You'd need to add a "should" statement about that to cover that
| case too.

I don't follow.

If I select an element out of one document and drop it into another,
it carries with it the in-scope namespaces that it had in its original
context. Namespace fixup may be required to establish the proper
bindings in the new context.

If you unwrap an element, it still carries with it the in-scope
namespaces that it had in its original context. Namespace fixup may be
required to establish the proper bindings in the new context.

How are those two situations not entirely analagous?

|> bearing in mind that namespace fixup says:
|>    [Definition: Some steps can produce XML documents which have no
|>    direct serialization (because they include nodes with conflicting
|>    or missing namespace declarations, for example). To produce a
|>    serializable XML document, the XProc processor must sometimes add
|>    additional namespace nodes, perhaps even renaming prefixes, to
|>    satisfy the constraints of Namespaces in XML. This process is
|>    referred to as namespace fixup.]
|> The advantage of these global statements over more specific ones is
|> twofold: first, they apply to all of the changes that are necessary,
|> even ones that may accidentally be left out a specific, per-step list
|> of requirements and second, they apply not only to our steps but to
|> implementation- and user-defined steps as well.
| I'm fine with having a global statement but I really prefer we define a
| repeatable behavior.  In each of the cases I outline a reasonable
| strategy for both preserving and generating namespace declarations so
| that namespace fixup does not have to occur.

Yes. But describing the fixup in detail for each step still introduces
the possibility of errors in the detailed description and leaves open
the possibility that we'll forget one or another bit of fixup on a
particular step. Furthermore, the detailed descriptions for our steps
do nothing to foster correct behavior from extension steps.

Having a global set of rules covers all of these cases and I don't see
how it fails to address any of the issues that the detailed
explanations cover.

|> | We can't quite go to last call without addressing this.
|> | p:add-attribute had a statement
|> | about adding a namespace declaration and that is now labeled "FIXME".   Up until
|> | now, no one has had issue with that sentence.
|> Oversight. I should have deleted that sentence. It's now covered by
|> 2.6.1.
| I really believe our steps should not to generate infosets that
| require namespace fixup.  In most cases, a simple statement would
| suffice.

I don't believe there was working group consensus to require that all
steps produce only fixed up documents. I think it would be better if
there had been, but there wasn't.

                                        Be seeing you,

Norman Walsh <ndw@nwalsh.com> | He that shuns trifles must shun the
http://nwalsh.com/            | world.--George Chapman

Received on Monday, 10 September 2007 19:53:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:44 UTC