- 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, norm -- 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