- 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