- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 26 Jun 2007 15:01:15 -0700
- To: ebruchez@orbeon.com
- Cc: public-forms@w3.org, www-forms-editor@w3.org, www-forms-editor-request@w3.org
- Message-ID: <OF6D9393DE.1244CBE9-ON88257306.0078753C-88257306.0078F85D@ca.ibm.com>
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/
Received on Tuesday, 26 June 2007 22:01:39 UTC