- From: T. V. Raman <tvraman@us.ibm.com>
- Date: Fri, 30 Aug 2002 14:57:54 -0700
- To: "Tomayko, Ryan" <Ryan_Tomayko@stercomm.com>
- Cc: joern turner <joern.turner@web.de>, www-forms@w3.org, xforms@yahoogroups.com
good point.
Not only will xinclude help here --simple perl script on the server
that stitches things together is what the average apache hacker is
likely to use --rather than wait for the standards world to specify a
solution.
Ultimately, there are standards, there are implementations of
standards, and the deployment of standards.
Given how long it takes to get a standard developed and signed off on,
it's a good thing that working groups dont also fall into the hole of
specifying how one deploys the technology;
think how long it would take to develop Apache 0.1 if this weren't the
case:-)
>>>>> "Tomayko," == Tomayko, Ryan <Ryan_Tomayko@stercomm.com> writes:
>> > 1. In order to create a reusable XForms document, the
>> document could > assume no knowledge of the host language
>> (profile). i.e. The XForms > document could not contain
>> elements or attributes from the host > languages namespace.
>>
>> i agree with your first sentence here, but disagree with the
>> second: there's no need for a form-processor to deal with the
>> host-language at all (see above). that's why namespaces are so
>> cool - why not ignore what you're not interested in ?
Tomayko,> Yes, definitely. I should have been more clear on my
Tomayko,> statement. The implementation I'm working on supports
Tomayko,> HTML+XForms and could support WML+XForms very
Tomayko,> easily. The XForms Processor ignores all non XForms
Tomayko,> markup.
Tomayko,> I was speaking more toward building cross-profile
Tomayko,> *documents*, not cross-profile processors. There is no
Tomayko,> way to build a single generic XForms document and have
Tomayko,> it run on either a web browser or a wireless device. You
Tomayko,> have to author two documents - one for each host
Tomayko,> language. The spec doesn't attempt to accommodate
Tomayko,> profile independent XForms (that's a statement not a
Tomayko,> complaint).
Tomayko,> XForms presentation needs a host language to make it
Tomayko,> meaningful but XForms data/logic markup (xforms:model)
Tomayko,> is meaningful without any host language at all. The
Tomayko,> difference is that operations on the data layer are
Tomayko,> always the same regardless of host language but
Tomayko,> operations on presentation are dependant on host
Tomayko,> language.
Tomayko,> Let's say I have four documents that do the same thing
Tomayko,> for different devices: a HTML+XForms, WML+XForms,
Tomayko,> SVG+XForms, and a HDML+XForms document. I need all four
Tomayko,> versions because I want full control over each
Tomayko,> presentation language. However, when I want to change a
Tomayko,> validation rule, I need to make that change in all four
Tomayko,> documents. This is unnecessary. There's no reason for
Tomayko,> the model definition to be specified in all four
Tomayko,> documents.
Tomayko,> The reason I haven't posted my concern to the
Tomayko,> www-forms-editor list is because XInclude will do the
Tomayko,> job today.
Tomayko,> <html> <head> <xi:include src="shared-model.xml"/>
Tomayko,> </head> ... </html>
Tomayko,> - Ryan
Tomayko,> -----Original Message----- From: joern turner
Tomayko,> [mailto:joern.turner@web.de] Sent: Thursday, August 29,
Tomayko,> 2002 6:21 PM To: Tomayko, Ryan Cc: www-forms@w3.org;
Tomayko,> xforms@yahoogroups.com Subject: Re: XForms Reusability /
Tomayko,> Modularization (was RE: XForms WD 20020821 - 2.1 XForms
Tomayko,> and XHTML etc)
Tomayko,> excellent analysis of an old XForms problem and
Tomayko,> completely agreed!
Tomayko,> i always considered XForms as a way to define
Tomayko,> cross-platform forms (so i share Andrew's naive
Tomayko,> perspective) and therefore tried to find solutions
Tomayko,> delivering that (in principle) even if the official spec
Tomayko,> doesn't necessarily reflect/considers this issue (yet).
Tomayko,> IMHO cross-platform capability is a key requirement for
Tomayko,> a generic form standard and i don't see why XForms
Tomayko,> shouldn't be capable to deliver that one day.
Tomayko,> maybe another perspective may add value to this
Tomayko,> discussion: shouldn't form-processsing be considered
Tomayko,> separately from form-rendering (excuse the implication
Tomayko,> to visual output here) ?
Tomayko,> for the purpose of form-processing no knowledge of the
Tomayko,> host language is needed, cause it deals only with
Tomayko,> elements from the xforms namespace (mainly doing
Tomayko,> manipulations on the model).
Tomayko,> but when rendering is done the host markup provides the
Tomayko,> additional information needed for layout and this is
Tomayko,> where the trouble starts...
Tomayko,> i think the whole problem is introduced when XForms
Tomayko,> solely builds on mixed-markup for solving the layout
Tomayko,> problem. i say 'solely' cause mixed-markup may still be
Tomayko,> used without making trouble for smaller projects. but
Tomayko,> for larger apps is highly wishable (and a matter of
Tomayko,> cost) to separate layout from the logical structure of
Tomayko,> the UI. so, other alternative ways to deal with layout
Tomayko,> should be provided/possible...
Tomayko,> Tomayko, Ryan wrote:
>> Andrew raises some excellent points here and one worth digging
>> further into.
>>
>>
>> << How is a cross-platform XForms document to be written?
>>
>> If the XForms code for the XHTML desktop platform is to be
>> separated (as the
>>
>> text quoted above suggests) into the xforms:model in the head
>> element and the XForms form controls in the body element how is
>> that to be adapted for, for example, use in an SVG and XForms
>> Profile or for embedding in WML or other languages to be used
>> on various mobile platforms.
>>
>> I had naively assumed that XForms would be "write once, run
>> everywhere" but if we are to carve up the XForms model and form
>> controls according to (ill
>> defined?) demands of host languages it seems that there will be
>> a lot of rewriting and tweaking of XForms code to be done.
>>
>>
>> Nail on the head. With the current facilities, it is absolutely
>> impossible to write an XForms document which would be used in
>> multiple host languages without modification. The reason's for
>> this are as follows:
>>
>> 1. In order to create a reusable XForms document, the document
>> could assume no knowledge of the host language
>> (profile). i.e. The XForms document could not contain elements
>> or attributes from the host languages namespace.
>>
Tomayko,> i agree with your first sentence here, but disagree with
Tomayko,> the second: there's no need for a form-processor to deal
Tomayko,> with the host-language at all (see above). that's why
Tomayko,> namespaces are so cool - why not ignore what you're not
Tomayko,> interested in ?
>> 2. "XForms always requires such a host language." (Section 3)
>>
>>
>> Alright, so it seems that there just isn't going to be entire
>> XForms Documents which are capable of being
>> "cross-profilable". So, let's look at this in pieces. What are
>> the reusable parts and which are not? Let's assume we need to
>> write both SVG and an HTML versions of the same XForm. What
>> could we write once and what would we need to write in each
>> profile.
Tomayko,> why not use XHTML (or any other XML markup language) to
Tomayko,> hold your forms - nobody urges you to interpret any of
Tomayko,> the html elements for the purpose of processing. if it
Tomayko,> comes to rendering you could e.g. use an additional
Tomayko,> 'user-agent' parameter and select an appropriate
Tomayko,> transformation to convert xforms ui elements into the
Tomayko,> ones used by the target language (e.g. xforms:input ->
Tomayko,> html:input, -> java.awt.textfield - see below)
>> 1. Instance Documents
>>
>> These are definitely reusable across XForms Documents in
>> different host languages.
>>
>> 2. Models (and all that's in them)
>>
>> Hmmmm.. There's nothing in XForms that allows "importing" a
>> model from a separate file but maybe there should be. There is
>> nothing inside a model element that should require a specific
>> host language. This makes models reusable in theory, there just
>> isn't any way (built into XForms) of importing them. Maybe a
>> src attribute on the xforms:model element would do the trick.
>>
>> XInclude could be used to import models. If you knew whatever
>> was processing the doc was capable of handling XInclude
>> elements, models could be maintained in separate files and
>> included into the host language.
>>
>> 3. User Interface Controls
>>
>> No way. I see very little hope for being able to use the same
>> UI controls across different languages. To be more specific,
>> you will not be able to modify an xforms:select1 element in a
>> single place and have the changes propagate to each host
>> language. XInclude is not even helpful here. Even if XForms
>> provided some method for reusing UI controls, it wouldn't be
>> much use as you will undoubtedly want to tweak at least one UI
>> control in the document for each host languages.
>>
>> This is why it's important that so much information be stored
>> at the model level (relevance, readonly, required, etc..). The
>> only things that should be specified on UI controls is the node
>> it references (ref or bind) and any host language specific user
>> interface stuff (CSS).
>>
>> Any other comments on this topic are greatly appreciated. I
>> like the idea of looking outside of XForms itself to provide
>> modularity (i.e. XInclude). Can anyone think of how XSLT might
>> be used to combine a pure XForms document with a host language
>> document and get a "Host Language + XForms" result? I have some
>> vague ideas but none worth leaving my head.
Tomayko,> i'm currently working along the following lines.
Tomayko,> provide two ways to generate the UI: [1] mixed-markup as
Tomayko,> proposed by spec - this ties the form to the
Tomayko,> host-language as you've stated, but is ok, if you only
Tomayko,> want to serve one client or for prototyping
Tomayko,> [2] consider the XForms UI of a given form a
Tomayko,> meta-description of a UI which is to be transformed into
Tomayko,> target client language. this requires to write a mapping
Tomayko,> for each UI element to the appropriate target language
Tomayko,> element (html:input, java.awt.textfield, whatever)
Tomayko,> e.g. as a XSLT transformation AND provide a layout
Tomayko,> transformation to be applied on the result of the first
Tomayko,> transform. this allow to separate layout from the
Tomayko,> logical description of the UI in XForms.
Tomayko,> this also solves applying company-styles on many forms
Tomayko,> even when there's no CSS.
Tomayko,> Joern
>> - Ryan
>>
>>
>> -----Original Message----- From: AndrewWatt2001@aol.com
>> [mailto:AndrewWatt2001@aol.com] Sent: Thursday, August 29, 2002
>> 7:36 AM To: www-forms@w3.org; www-forms-editor@w3.org;
>> xforms@yahoogroups.com Subject: XForms WD 20020821 - 2.1 XForms
>> and XHTML etc
>>
>>
>>
>> In Chapter 2.1, it is stated (without further explanation):
>>
>> "This can be represented in the XForms model element, which in
>> XHTML would be contained within the head element".
>>
>> It seems to me that this is not a statement that can be made
>> without qualification. It is not, as far as I am aware, true
>> for XHTML 1.0. Therefore I suggest that consideration be given
>> to adding a version number to the statement.
>>
>> In addition, as far as I can see, there is nothing in the
>> initial XHTML 2.0 WD which constrains the xforms:model element
>> to being present nested in
Tomayko,> the
>> XHTML head element. Is there anything to prevent the
>> xforms:model element being present in the body element but
>> simply not be rendered?
>>
>> Did I miss something? Or is the XForms WD making an assumption
>> that may not necessarily be true? If it is merely an assumption
>> then some redrafting might be in order.
>>
>> It also raised, for me at least, an issue which I hadn't
>> considered in detail before. This is partly because I had
>> focussed on using XForms on a single platform as I tried to get
>> to grips with the detail of XForms.
>>
>> How is a cross-platform XForms document to be written?
>>
>> If the XForms code for the XHTML desktop platform is to be
>> separated (as the
>>
>> text quoted above suggests) into the xforms:model in the head
>> element and the XForms form controls in the body element how is
>> that to be adapted for, for example, use in an SVG and XForms
>> Profile or for embedding in WML or other languages to be used
>> on various mobile platforms.
>>
>> I had naively assumed that XForms would be "write once, run
>> everywhere" but if we are to carve up the XForms model and form
>> controls according to (ill
>> defined?) demands of host languages it seems that there will be
>> a lot of rewriting and tweaking of XForms code to be done.
>>
>> Is there a mechanism which I am overlooking which will allow
>> modular XForms code to be re-used as is across platforms?
>>
>> Am I missing something obvious here, which is always possible?
>> Or is creation of cross-platform XForms code going to be less
>> transparent than I had (naively?) assumed?
>>
>> Andrew Watt
>>
>>
--
Best Regards,
--raman
------------------------------------------------------------
T. V. Raman: PhD (Cornell University)
IBM Research: Human Language Technologies
Architect: Conversational And Multimodal WWW Standards
Phone: 1 (408) 927 2608 T-Line 457-2608
Fax: 1 (408) 927 3012 Cell: 1 650 799 5724
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 Friday, 30 August 2002 17:58:17 UTC