- From: John Boyer <boyerj@ca.ibm.com>
- Date: Mon, 20 Sep 2010 11:25:34 -0700
- To: Leigh L Klotz Jr <leigh.klotz@xerox.com>
- Cc: public-forms@w3.org
- Message-ID: <OFA9898486.76B09657-ON882577A4.00621280-882577A4.00653959@ca.ibm.com>
Oh... ha. I hadn't realized this is what you were asking me, Leigh. I had thought you were asking me if it would be better to allow *arbitrary* mixing of UI common elements with list UI common elements, e.g. some help, some items, some actions, an itemset, an alert, some more items, ... My supposition is that at least some run-time implementations would have no problem with this, but undoubtedly some will. That being said, I believe that whoever does have problems with it will almost always prefer *your* RNG way of fixing this because it would be easier to get themselves into conformance. The action item I received [1] did indeed request putting UI common both before and after the List, but your RNG way is an alternative change I could really get behind because it remains easy to specify and to encode in XML schema without a surgery and makes the minimal change that fixes the authoring problem we intended to fix. [1] http://lists.w3.org/Archives/Public/public-forms/2009Dec/att-0021/2009-12-09-v2.html#ACTION2 Please post a correction if you think the following will not work. For select1 and select, rather than <xsd:element name="select1"> <xsd:complexType> <xsd:sequence> <xsd:element ref="xforms:label"/> <xsd:group ref="xforms:UI.Common" minOccurs="0" maxOccurs="unbounded"/> <xsd:group ref="xforms:List.UI.Common" maxOccurs="unbounded"/> <xsd:group ref="xforms:UI.Common" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> ... a change that would synch with the RNG fix would seem to be: <xsd:element name="select1"> <xsd:complexType> <xsd:sequence> <xsd:element ref="xforms:label"/> <xsd:choice> <xsd:sequence> <xsd:group ref="xforms:UI.Common" minOccurs="0" maxOccurs="unbounded"/> <xsd:group ref="xforms:List.UI.Common" maxOccurs="unbounded"/> </xsd:sequence> <xsd:sequence> <xsd:group ref="xforms:List.UI.Common" maxOccurs="unbounded"/> <xsd:group ref="xforms:UI.Common" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:choice> </xsd:sequence> ... Thanks, John Boyer From: Leigh L Klotz Jr <leigh.klotz@xerox.com> To: public-forms@w3.org Date: 09/20/2010 10:38 AM Subject: XForms 1.1 erratum for select and select1 and ordering of help/hint/alert/action John and I implemented the select and select1 content model erratum differently. At the time, we polled implementors and asked if any cared about whether the help/hint/alert/action had any ordering constraints against item and itemset, and the answer was no. Unfortunately, we're in a state at the moment with the proposed erratum in the wiki [errata] and the RNG schema are at odds. So the question is: Must UI Common content all be together, or can be be split with some before the List and some after? Since we asked implementors before what they accepted, I'd like to ask again if anyone cares so we can fine-tune the erratum and the schema. Details: Here's what the XForms 1.1 RNC says: xforms.select1.content = xforms.label, ((xforms.UI.Common.content, xforms.List.UI.Common.content) | (xforms.List.UI.Common.content, xforms.UI.Common.content)) The proposed erratum says this: label, (UI Common)*, (List UI Common)+, (UI Common)* To be consistent with the proposed erratum, we'd change the RNC to this: xforms.select1.content = xforms.label, xforms.UI.Common.content, xforms.List.UI.Common.content, xforms.UI.Common.content Or, we would change the proposed erratum to this: label, ((UI Common)*, (List UI Common)+) | ((List UI Common)+, (UI Common)*) [errata] http://www.w3.org/MarkUp/Forms/wiki/XForms_1.1_First_Edition_Errata Leigh.
Received on Monday, 20 September 2010 18:26:12 UTC