W3C home > Mailing lists > Public > www-forms@w3.org > August 2002

Re: XForms Reusability / Modularization (was RE: XForms WD 200208 21 - 2.1...

From: <AndrewWatt2001@aol.com>
Date: Fri, 30 Aug 2002 03:01:30 EDT
Message-ID: <3c.236cc20d.2aa0724a@aol.com>
To: Ryan_Tomayko@stercomm.com
CC: www-forms@w3.org, xforms@yahoogroups.com
In a message dated 30/08/2002 04:11:13 GMT Daylight Time, 
Ryan_Tomayko@stercomm.com writes:

> The reason I haven't posted my concern to the www-forms-editor list is
> because XInclude will do the job today.
>     <head>
>         <xi:include src="shared-model.xml"/>
>     </head>


I guess you mean
 <xi:include href="shared-model.xml"/>

But doesn't XInclude (at least at the current stage of development of the 
XForms WD) potentially make things worse?

If I am trying to write an XForms-using application to be processed 
client-side independent of platform how will I be able to know whether the 
user agent/browser is or is not XInclude-capable?

If I can't detect that then how can I know whether all-in-one.svg should be 
sent or shared-model.xml plus form-controls.xml should be sent to be 
XIncluded by the receiving client application?

So, if there are XInclude-capable and XInclude-incapable XForms-using 
browsers out there don't I have to create and maintain a single platform 
all-in-one document plus XInclude-capable versions? If that's the case then 
doesn't the maintenance burden become even worse?

I can see that using XInclude may help IF you are sure that the user agent is 
XInclude capable. This again brings us back to the question of how generic 
(or non-generic) a proposed solution the current WD of XForms is.

Andrew Watt
Received on Friday, 30 August 2002 03:02:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:44 UTC