Forwarded message 1
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/