RE: XForms WD 20011207 - document architecture

At 01:54 PM 12/13/2001 -0800, Micah Dubinko wrote:
>I expect similar for various combinations of XForms with other languages. It
>is a form of layering brought about by necessity. It's easy to imagine
>XForms integrated with some new markup language that doesn't exist today.
>Until time travel technology improves, that sort of thing will never make
>XForms 1.0. ;-)

Point taken..

Jim



>.micah
>
>-----Original Message-----
>From: Jim Wissner [mailto:jim@jbrix.org]
>Sent: Thursday, December 13, 2001 1:42 PM
>To: Micah Dubinko
>Cc: www-forms@w3.org
>Subject: RE: XForms WD 20011207 - document architecture
>
>
>At 12:21 PM 12/13/2001 -0800, you wrote:
> >For every containing document, there needs to be some additional work to
> >define such things (for instance, XHTML 2.0 will be a biggie). So, in
>
>Can you explain what you mean here?  By "define" do you mean explain, or do
>you mean there will be constraints in the spec that will need to be
>followed?  And, if there will be additional constraints in the spec for
>specific markup languages, what does this mean for non-standard
>containers?  Is this the layered spec approach that Ryan spoke of?
>
>Thanks,
>Jim
>
>
> >document types that have a concept of a separate head and body sections,
>the
> >XForms 1.0 document provides guidance on how to design the new combined
> >document type. Obviously, in document types without head/body separation,
> >the closest approximation needs to be used.
> >
> >Thanks,
> >
> >.micah
> >
> >-----Original Message-----
> >From: Tomayko, Ryan [mailto:Ryan_Tomayko@stercomm.com]
> >Sent: Wednesday, December 12, 2001 8:29 AM
> >To: 'www-forms@w3.org'
> >Subject: RE: XForms WD 20011207 - document architecture
> >
> >
> >IMO, the WG has done a terrific job at balancing the level of separation of
> >XForms functionality from specific UI markups (considering the pressure
>they
> >must be receiving for delivering the next generation of *HTML* [bread and
> >butter] forms). The fact that the specification lays down rules for use in
> >XHTML should not be considered a negative aspect of the specification.
> >
> >Imagine the implementation incompatibilities you would have if the spec
>were
> >more vague in this area. I would argue that further specifics on how XForms
> >works into XHTML is in order, not less. Further, if other UI markups are to
> >be supported (WML/HDML/XSL-FO for instance), I would suggest amendments or
> >sub-specifications that go deeper into implementation details for these
> >standards.
> >
> >Attacking the inclusion of HTML specific constructs in the spec may be
> >misguided. Perhaps what is needed is a more layered approach to defining
> >these constructs. For example, the XForms Core Specification, The XForms
> >XHTML Spec, The XForms WML Spec, etc.. Perhaps not. At any rate, I find it
> >unrealistic to assume that this specification could be implemented by
> >multiple vendors with any kind of compatibility if not for the references
>to
> >HTML.
> >
> >- Ryan
> >
> >
> >-----Original Message-----
> >From: Jim Wissner [mailto:jim@jbrix.org]
> >Sent: Wednesday, December 12, 2001 11:01 AM
> >To: JOHANSSON, Justin; 'www-forms@w3.org'
> >Subject: Re: XForms WD 20011207 - document architecture
> >
> >
> >At 04:57 PM 12/12/2001 +1030, JOHANSSON, Justin wrote:
> > >4.3.1. model states:
> > >
> > >"Element model is used as a container for other XForms elements, embedded
> > >in the head section of other document types such as XHTML. ...."
> > >
> > >Also while not spelt out in the spec, it is implied that the form
>controls
> > >themselves are embedded in an element called "body" in the document.
> > >
> > >What's wrong with this is that the spec is imposing a head/body structure
> >on
> > >
> > >the document.  That's fine for HTML/XHTML but that's not find for XML
> > >documents in the general case.  Who says that a valid and well-formed
> > >XML document must adhere to a head/body pattern?  The XML spec
> > >certainly does not.  Therefore in constructing a consistent set of
> >standards
> > >
> > >in which XForms should fit in with XML, the XForms spec should not
> > >impose such structure on the document itself and there needs to be
> > >a general purpose XML-ish way of associating the xforms controls
> > >with the xforms model element.
> > >
> > >Actually I which every XML document did have a head/body structure and
> > >that would make life easier for everyone.  However XSL documents
> > >(eg. the W3C XMLspec.xsl) do not have head/body elements.  There
> > >may be some valid reason for wanting to use XForms in an XSL
> > >document such as in a web authoring application and such forethought
> > >should be considered in the XForms spec.
> >
> >There absolutely is, you are right, or any other non-standard XML
> >document.  Any non-html-variant application that wants to leverage re-use
> >of forms.  But I'll state again, that while the spec does give a bit of
> >service to other clients such as voice browsers, there are enough hints of
> >HTML to suggest it's still biased strongly this way, and that there hasn't
> >really been a complete clean-slate approach that would be free of these
> >kinds of "idiosyncrasies."  Yes, they are covering the bases of the largest
> >likely potential platforms, but they are also (IMHO) making it in such a
> >way that it resists breaking free into new kinds of interfaces.
> >
> >Anyway, I won't go over all of my previous issues again, but I'll just say
> >I agree with you 100%, and the problem you cited isn't the only one in the
> >spec that would present problems to a "non-head/body structure XML
> >document."
> >
> >Jim
> >
> >
> >
> >
> >--
> >jim@jbrix.org
> >
> >Visit www.jbrix.org for:
> >    + SpeedJAVA jEdit Code Completion Plugin
> >    + Xybrix XML Application Framework
> >    + other great Open Source Software
>
>--
>jim@jbrix.org
>
>Visit www.jbrix.org for:
>    + SpeedJAVA jEdit Code Completion Plugin
>    + Xybrix XML Application Framework
>    + other great Open Source Software

--
jim@jbrix.org

Visit www.jbrix.org for:
   + SpeedJAVA jEdit Code Completion Plugin
   + Xybrix XML Application Framework
   + other great Open Source Software

Received on Friday, 14 December 2001 16:05:07 UTC