Re: Towards a consensus draft (urgent)

/ Alex Milowski <alex@milowski.org> was heard to say:
| 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.

I wasn't attempting to describe any API.

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

I'm confused. The definition of the in-scope namespaces property says:

  [in-scope namespaces] An unordered set of namespace information
  items, one for each of the namespaces in effect for this element.

That's a property *of the element* so, unless you do something change
it, I don't see how it could be unclear that it travels with the
element.

If we say

  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.

I don't see where a problel arises.

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

No. Your API may not do a good job of preserving the [in-scope namespaces]
property. But that's your problem.

| To be clear, we need to say that the in-scope namespaces
| are preserved for descendants.

I suppose we can try to be clearer. Perhaps this text after the first
paragraph in 2.6.1:

   Most steps in this specification manipulate XML documents, or
   portions of XML documents. In these cases, we speak of changing
   elements, attributes, or nodes without prejudice to the actual
   representation used by an implementation. Unless a step explicitly
   says otherwise:

   * the in-scope namespaces associated with a node (even those that
     are inherited from namespace bindings that appear among its
     ancestors in the document in which it appears initially) are
     assumed to travel with it.

   * changes to one part of a tree (wrapping or unwrapping a node or
     renaming an element, for example) do not change the in-scope
     namespaces associated with the descendants of the node so
     changed.

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

Does the above help?

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

Yeah? Programming is hard work.

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

You're suggesting that we have two descriptions for a process. I think
that's always a mistake in a specification as it simply introduces the
possibility (ne probability) that conflicting interpretations will be
possible.

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

You've run into buggy software? I'm shocked! Shocked, I say! :-)

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

Are you asking me to re-open this question?

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | 'tis expressly against the law of arms:
http://nwalsh.com/            | 'tis as arrant a piece of knavery, mark
                              | you now, as can be offer't; in your
                              | conscience, now, is it not?--Fluellen,
                              | Henry V