Re: XForms 1.1 erratum for select and select1 and ordering of help/hint/alert/action

Agreed, I suggest we dump XML  Schema --- we only used it because
at one point in history, we would not have been allowed to move
ahead in the W3C  Process if we hadn't used it.  Given that those
rules are no longer being applied by the W3C, it's time to shelve
the baggage.

Erik Bruchez writes:
 > John,
 > 
 > I don't want to create more work than needed for such a small change.
 > 
 > It's just a shame that we have to specify our grammar in an unsatisfactory way
 > just because XML Schema is too weak to accomodate something that simple. In
 > other words XML Schema shows once again to be the wrong tool to describe or
 > supplement our grammar.
 > 
 > And I say unsatisfactory because the trend on the web these days is not to
 > constrain more, but to constrain less, and certainly not to constrain when
 > unnecessary. Here the restriction seems unnecessary both for implementors and
 > form authors - it just seems necessary for the schema authors ;)
 > 
 > And then there is what we say in the spec and schema, and what implementations
 > and form authors will actually do. My guess is that implementations typically
 > do not enforce these constraints in general, simply because there is no need
 > to. If that's the case, our schema is kind of irrelevant for this particular
 > purpose.
 > 
 > This said I don't have a good solution either (except for dropping XML Schema
 > altogether but that's probably another topic).
 > 
 > -Erik
 > 
 > On Mon, Sep 20, 2010 at 3:27 PM, John Boyer <boyerj@ca.ibm.com> wrote:
 > 
 >     Well, allowing full and arbitrary mixing of UI common and list UI common
 >     elements is what I thought Leigh was asking me to do.
 >    
 >     It's one thing to say to do it "whatever the impact on the XForms schema
 >     might be" but it's another to be the person who has to do the surgery on
 >     both the XML schema and RNG schema, and then *sell* that as a minor
 >     change.
 >    
 >     In this regard, I like the working group approach better because it is a
 >     minimal schema change that has maximal effect in terms of what authors are
 >     actually likely to do.  They probably are likely to group the UI common
 >     elements together.  The real issue we're trying to fix is that they are
 >     likely to group them together right after the label element, for
 >     consistency with other UI controls.  The schema as-is is certainly too
 >     restrictive. The working group decided to fix it by allowing UI.common
 >     before List UI common as well as after.  That's been done.  A more
 >     powerful solution *could* be achieved as long as someone is willing to
 >     spend time on it, but someone != me because because it does not give much
 >     practical benefit over the solution we already chose.  But if this topic
 >     is a high priority for anyone else, I certainly don't object to them
 >     taking it on.
 >    
 >     Anyway, Leigh did an alternative change in RNG, before the WG decision.
 >      It is slightly more restrictive, and now he's asking whether we should go
 >     with that or go with the solution encoded in the XML schema.
 >    
 >     I liked the working group's solution because it was the most certain to
 >     work in XML schema, but I also like Leigh's solution because it is the
 >     minimum change of validating content that still solves the problem of
 >     allowing author consistency across UI elements.  
 >    
 >     However, something felt a little fishy about it, so I asked a co-worker at
 >     my office to try out the XML schema fragment that seemed to match Leigh's
 >     RNG expression.  Unfortunately, it does not work and it appears that XML
 >     schema does not allow this type of construct, at least not without more
 >     effort (and please see above for my view on how much effort I think should
 >     be spent on this).
 >    
 >     The technical error we get is "Unique Particle Attribution" error.  This
 >     happens because XML schema expects to be able to unambiguously determine
 >     what is going on with only local content particles (a constant-sized
 >     lookahead). When you have
 >    
 >     <select 1 ...>
 >             <label>...
 >             <itemset ...> ...
 >     </select1>
 >    
 >     It would validate against both (UI.Common* List.UI.Common+) and
 >     (List.UI.Common+ UI.Common*).
 >     However, it looks like XML schema processors want to choose which one of
 >     these to use based on at most the first element after label, the <itemset>
 >     in this case.  But because we have UI.Common* at the front of the first
 >     rule, both it and the second rule are applicable, which is ambiguous.
 >    
 >     The problem worsens, I think, with
 >    
 >     <select 1 ...>
 >             <label>...
 >             <itemset ...> ...
 >             <hint>...
 >     </select1>
 >    
 >     because clearly only the second rule applies, but apparently XML schema
 >     only looks as far as the itemset and gives up before knowing that one of
 >     the rules will fail and the other will succeed.
 >    
 >     It appears that RNG keeps going and allows the content if one or more of
 >     the choices will validate the content.
 >    
 >     Long story short, the most expedient solution to our problem is to keep
 >     the erratum as-is and change the RNG schema.
 >    
 >     Cheers,
 >     John
 > 
 >     From:    Erik Bruchez <ebruchez@orbeon.com>                               
 >     To:      public-forms@w3.org                                              
 >     Date:    09/20/2010 11:34 AM                                              
 >     Subject: Re: XForms 1.1 erratum for select and select1 and ordering of    
 >              help/hint/alert/action                                           
 > 
 >     --------------------------------------------------------------------------
 > 
 >     It seems to be an unnecessary constraint for the form author to
 >     mandate that UI Common elements be all grouped together. So my vote
 >     goes for the more lax solution, whatever the impact on the XForms
 >     schema might be.
 >    
 >     -Erik
 >    
 >     On Mon, Sep 20, 2010 at 10:35 AM, Leigh L Klotz Jr
 >     <leigh.klotz@xerox.com> wrote:
 >     > 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.
 >     >
 >     >
 > 

-- 
Best Regards,
--raman

Title:  Research Scientist                              
Email:  raman@google.com                                
WWW:    http://emacspeak.sf.net/raman/                  
Google: tv+raman                                        
GTalk:  raman@google.com                                
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

Received on Tuesday, 21 September 2010 23:36:17 UTC