Foreign form controls -- ambiguity in XForms 1.0

This is a red herring.
As stated in the abstract XForms is not a stand-alone document type.

Since ourA) we are not a stand-alone document type, and B) our binding
mechanism is designed to work independent of our UI vocabulary, it's
up to the document profile integrating XForms to decide how to use its
UI vocabulary with XForms binding e.g. Voice XML

Talking about foreign name space elements inside XForms makes no sense
because it is XForms that will be the "foreign namespace" in whatever
document type contains it.


I apologize for discussing this on the editors list,
but the  given that a member of the WG chose to post this here as a
last call comment, rather than discuss it on the WG list first,
in full detail, I feel the response is warranted.

Micah Dubinko writes:
 > Beyond signature controls, others have expressed the desire to incorporate
 > other form controls, tree controls for instance, into XForms. Other groups,
 > such as VoiceXML, also wish to build specific solutions from the general
 > framework of XForms. There's a need to express form controls outside of the
 > core set defined in XForms 1.0.
 > 
 > Note that (X)HTML allows the <object> tag as a data-submitting form control.
 > This has been rarely used, but the limited data representation of HTML form
 > data no doubt contributed to that.
 > 
 > The spec is not clear on 1) whether foreign form controls are currently
 > allowed, and 2) if they are, what processing (if any) is applies.
 > 
 > The spec does clearly state:
 > "Note that except where specifically allowed by the Schema for XForms,
 > foreign-namespaced elements are not allowed as content of elements in the
 > XForms namespace."
 > 
 > Form control elements, however, can exist as content of the containing
 > document, not necessarily of an XForms element
 > 
 > <html:body>
 >   <xforms:input.../>
 >   <otherns:treecontrol../> ?
 > ...
 > and thus are not covered by the above statement.
 > 
 > To fix this, the XForms spec should be changed in one of the following ways:
 > 
 > 1) Clearly state that foreign form controls are not allowed.
 > 
 > 2) Clearly state that foreign form controls are allowed (and make sure
 > ##other is in the content models of <group>, <case>, <repeat>, etc..) and
 > specify concrete processing.
 > [note that the processing may very well be quite minimal, as is <object>
 > processing in HTML forms]
 > 
 > Given the opening paragraph, I would strongly favor the 2nd option. :-)
 > 
 > Thanks,
 > 
 > .micah

-- 
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman:  PhD (Cornell University)
IBM Research: Human Language Technologies
              Conversational And Multimodal WWW Standards
Phone:        1 (408) 927 2608
Fax:        1 (408) 927 3012
Email:        tvraman@us.ibm.com
WWW:      http://www.cs.cornell.edu/home/raman
AIM:      TVRaman
PGP:          http://emacspeak.sf.net/raman.asc
Snail:        IBM Almaden Research Center,
              650 Harry Road
              San Jose 95120

Received on Tuesday, 5 February 2002 22:38:07 UTC