Re: Question about resolution for action 105

Hi Erik,

The specific issue of attribute order was addressed satisfactorily at the 
face to face, i.e. the group spent longer on it than we really had and 
came to a resolution on this issue.  Perhaps it would have been resolved 
more quickly and more like the proposed alternative if we had had the 
benefit of you being there.  However, the working group did sufficiently 
consider the issue of attribute order and produced a wording that does not 
require support for attribute positioning beyond what is clearly needed 
within XPath.  In other words, we do not require attribute order to 
survive a DOM mutation, which the XPath data model does not address, but 
we continue to allow attributes to be in a particular order during 
evaluation of an XPath, which is allowed by XPath even if different 
implementations will produce different orders.  We believe that the result 
is a sufficient relaxation to allow the implementation phase (i.e. CR) to 
proceed.

Thanks,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: www-forms-editor-request@w3.org
06/25/2007 09:12 AM
Please respond to
ebruchez@orbeon.com


To
public-forms@w3.org
cc
www-forms-editor@w3.org
Subject
Question about resolution for action 105






All,

Just before the f2f, I agreed to do some more of the editorial work
related to xforms:insert and xforms:delete, namely related to the
issues I had submitted. I haven't done that work yet, but I was
looking at what was involved and I noted that there has been some
discussion at the f2f about issue 105:

   http://htmlwg.mn.aptest.com/cgi-bin/xforms-issues/Actions?id=105

Issue 105 is the same issue Joern raised quite a while ago, issue
about which I posted back in February (in our private mailing-list at
the time) a proposal for a resolution:

   http://lists.w3.org/Archives/Member/w3c-forms/2007JanMar/0114.html

For convenience, and in order to make the message public, I attach
this proposal again.

I am not sure I understand exactly the discussion or the resolution
taken at the last f2f, but I am not sure my proposal was looked at.

My proposal included updating point 6a, removing point 6b, and
updating point 6d as well (solution #2 in the proposal).

I proposed that we eliminate completely the need for talking about
attribute order or inserting among sibling attributes because that's a
flawed concept in my opinion. However, it seems that the f2f
resolution still talks about a "list", which I find disturbing because
a list implies order, and our wording seems to still want to allow the
user to manipulate this order.

I think we should favor a solution which does not require us to talk
about attribute order. In addition, I don't think there is much of a
use case for this anyway, and I don't think you can manipulate
attribute order in XSLT or other XML-based languages.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/

----- Message from Erik Bruchez <ebruchez@orbeon.com> on Tue, 20 Feb 2007 
14:37:22 +0100 -----
To:
Forms WG <w3c-forms@w3.org>
Subject:
Proposal for xforms:insert and attributes
All,

1. XML background
-----------------

As Joern pointed out a while ago, in XML, attributes do not have a
significant order. This is made clear in a few key specifications:

1. XML Information Set
    http://www.w3.org/TR/xml-infoset/#infoitem.element

    "[attributes] An unordered set of attribute information items, one
     for each of the attributes (specified or defaulted from the DTD)
     of this element. "

2.  XQuery 1.0 and XPath 2.0 Data Model (XDM)
     http://www.w3.org/TR/xpath-datamodel/#document-order

    "The relative order of Attribute Nodes is stable but
     implementation-dependent."

3. Document Object Model (DOM) Level 2 Core Specification
    http://www.w3.org/TR/DOM-Level-2-Core/core.html

    "Interface Node [...] Attributes [...] attributes of type
     NamedNodeMap, readonly [...] NamedNodeMaps are not maintained in
     any particular order. Objects contained in an object implementing
     NamedNodeMap may also be accessed by an ordinal index, but this is
     simply to allow convenient enumeration of the contents of a
     NamedNodeMap, and does not imply that the DOM specifies an order
     to these Nodes."

Ok, convinced yet? ;-)

As sides nodes, which may be useful to understand what follows:

o While attributes have an element as a parent (in XDM), or owner
   element (Infoset, DOM), elements do *not* consider attributes their
   children.

o Attributes don't have following or preceding siblings (in XDM,
   siblings are defined relative to the "children" property, which
   doesn't include attributes). See also XPath 1.0:

     "the following-sibling axis contains all the following siblings of
     the context node; if the context node is an attribute node or
     namespace node, the following-sibling axis is empty"

In short, the idea of attributes in XML is that they are unordered
name/value pairs that are part of the properties of an element. While
they are considered nodes, they do not behave like most other node
types (element, text, PI, and comment).

2. Current spec text and implications
-------------------------------------

The issue in the XForms 1.1 spec is in section "9.3.5 The insert
Action". I paste below the offending text:

   Point 6a and 6b:

     "If the cloned node is an attribute, then the target location is
      before the first attribute of the insert location node."

   Implicitly, point 6d:

     "Otherwise, the target location is immediately before or after the
      insert location node, based on the position attribute setting or
      its default."

This text suggests that you can:

1. Insert an attribute so that the attribute is the "first" of an
    element's attributes.

2. Insert an attribute "before" or "after" another attribute.

To be fair, some DOM implementations do represent attributes as a
list, and do allow implementing this behavior.

But the text strongly suggests that attribute order is a common
property of attributes in XML or DOM, while in reality it is not the
case at all. I believe that we need to correct the text to remove the
mention or implication of attribute order, and leave attribute order
to implementations. This is not an interoperability issue, as various
XML specifications tell us that we should not rely on attribute order
anyway.

3. What XForms 1.0 allows
-------------------------

As a reminder, in XForms 1.0, it was not possible to:

1. Insert an attribute *into* an element (nodes are only inserted
    before or after an existing node).

2. Duplicate attributes with something like this:

    <xforms:insert nodeset="@*" at="2" position="before"/>

    While I think that the above is allowed by the spec in XForms 1.0,
    it does not make any sense in XML as it means that an existing
    attribute is *duplicated*. And of course it is strictly forbidden
    to have duplicate attributes (i.e. two attributes with the same
    QName) in XForms.

So when we are talking about inserting attributes in XForms 1.1, we
are talking about a new feature that was not previously available in
XForms 1.0.

4. What we need to change in XForms 1.1
---------------------------------------

Now back to what we need to be able to achieve in XForms 1.1. I think
that adding an attribute to a node is a necessary feature. This can be
achieved with:

   <xforms:insert context="my-element" origin="instance('foo')/@bar"/>

This case is covered in point 6a and 6b (BTW I recommended removing 6b
in a previous email). I recommend we update the text to the following
in 6a (and again, remove point 6b):

   "If the cloned node is an attribute, then the target location is as
    an attribute of the insert location node."

I am now 100% happy with the "location is as..." formula, which
doesn't sound very English. If somebody has a better suggestion, let
me know, but I think this is understandable.

Now case 6d covers the case where we insert as a "sibling" of other
nodes. This case is funny because, as I mention above, attributes
don't have siblings. We have at least two choices here:

1. Change 6d as follows:

    "Otherwise, if the insert location node is an attribute and the
     cloned node is an attribute, the target location is as an
     attribute of the element owning the insert location
     node. Otherwise, the target location is immediately before or
     after the insert location node, based on the position attribute
     setting or its default."

     (Note that as usual invalid node combinations are covered in point
     7.)

     This does away with the idea that you insert an attribute "before"
     or "after" another attribute. This I think is the least we can do.

2. Or conclude that the whole concept of inserting an attribute as
    preceding or following sibling of another attribute is flawed, and
    simply consider that trying to do so should simply nop. When
    writing something like:

      <xforms:insert nodeset="@*" at="2" position="before"
                     origin="instance('foo')/@bar"/>

    not only do we stretch the concept of sibling nodes, but also @at
    loses its meaning and so does @position. And really, what we are
    actually waying here is that we want to insert a node "into" a
    node-set, but forgetting that there is no underlying concept in XML
    for doing so.

    So this option would add to 6d (or add before 6d) the following:

    "Otherwise, if the insert location node is an attribute and the
     cloned node is an attribute, the cloned node is ignored."

I am leaning towards #2 because #1 is really a conceptual stretch and
because if the goal is to insert an attribute into an element, there
is already a syntax to do this.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/