Re: Towards a consensus draft (urgent)

On 9/10/07, Norman Walsh <ndw@nwalsh.com> wrote:
> 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.

I'm not certain that what you are describing is a well-defined behavior
for any API.  As such, we really need to be very clear.

After going back a reading your text again, I see you approach but
it needs to more explicit in that the original in-scope namespaces
of the original infoset element items need to be preserved on
copy or other manipulations.

>
> 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.

Again, depending on namespaces are handled, those bindings might
disappear.   To be clear, we need to say that the in-scope namespaces
are preserved for descendants.

We need to guarantee that in-scope namespaces are preserved for:

   * the in-scope namespaces of source items (e.g. inserted, copied, etc.)
   * the in-scope namespaces of target items (e.g. element children
being unwrapped)

I'm not certain that everyone would walk away with that impression
from the latest
draft.

I'll have to look at your precise wording and see if I can suggest something.

>
> How are those two situations not entirely analagous?

Analagous but not necessarily the same burden upon implementors.  In some
APIs (e.g. DOM), namespaces are handled as attributes.  It would be an
easy process to guarantee that the in-scope namespaces are correct for
inserted content but much harder for when you remove a parent and want
to preserve them for children.

>
> 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.

I'm suggesting we have both general rules and specific instructions for our
step library.

> 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.

Only by wishing that implementors do it right.  I've run into a lot of software
that fails because of "namespace fixup" issues.

>
> 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.

Obviously, I agree.  Anyone else?


-- 
--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 Monday, 10 September 2007 20:15:05 UTC