W3C home > Mailing lists > Public > www-forms@w3.org > September 2006

Re: Feedback on 1.1: instance src attribute broken

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Tue, 19 Sep 2006 12:34:09 +0100
Message-ID: <640dd5060609190434n5fdc556amb36b83ebdfed7ebe@mail.gmail.com>
To: "John Boyer" <boyerj@ca.ibm.com>
Cc: w3c-forms-request@w3.org, www-forms@w3.org, www-forms-editor@w3.org

Hi John,

I don't think we should either of us give the impression that one or
other of our positions is 'given' by the XForms spec.

You said in your previous email that the semantics of XForms is
different to the semantics of XHTML 2, in relation to the presence of
@src and inline instance data. I replied to say that it was pretty
easy to ensure that the semantics of both were suitably aligned, since
a common XForms use case is that the document referred to by @src
doesn't initially exist, therefore making the inline content of the
<instance> a useful 'fall back'.

Your reply below says that this is wrong and that actually the
semantics of XForms is that the content should take priority, and
'override' the @src.

However, given that XForms does not say *anything* about what should
happen if there is both an @src attribute and some inline content,
then neither of us is 'correct'! :) My position is simply that in the
absence of clearly defined behaviour, maintaining harmony with XHTML 2
(which is itself a generalisation of HTML/XHTML behaviour) is a pretty
good idea.

It's worth saying that your use case is premised on the idea that the
correct serialisation of an XForm 'in process' is to serialise the
contents of an instance as inline data, and at the same time to
preserve the value in the @src attribute. Obviously, that is not
something that can be found in the XForms spec itself, since the only
thing you can serialise is instance data, but it's certainly a
powerful and useful feature. But as with everything there are many
ways you can look at it, and in our work in this area we serialise the
current state of the instance as inline data (as you do), but we
_remove_ the @src attribute, since as far as XForms stands today, @src
specifies a document to be loaded on start-up, regardless of the
inline content. This has the major advantage that the 'serialised'
XForm can be passed to any other XForms processor, since it is just a
normal form.

(Which also means that this proposal is backwards compatible.)

Regards,

Mark

On 18/09/06, John Boyer <boyerj@ca.ibm.com> wrote:
>
>
> Hi Mark,
>
> To keep this short, I think that it's fine for XHTML2 to add a src attribute everywhere and to have the semantic it has.
>
> However, the semantic categorically does not fit the problem I described, so a separate attribute is needed by XForms.
>
> I will use the new attribute I propose to provide an example.  If I have an instance like this:
>
> <instance resource="http://www.example.org/defaultData.xml"/>
>
> Then, I expect that the instance data will come from the external resource, as follows:
>
> <instance resource="http://www.example.org/defaultData.xml">
>    <my xmlns="">
>       <name></name>
>     </my>
> </instance>
>
> Now suppose an input is bound to name, and I run this form and enter my name.  Then, because I have a save feature, I save the document to disk.  This is what it contains:
>
> <instance resource="http://www.example.org/defaultData.xml">
>    <my xmlns="">
>       <name>John</name>
>     </my>
> </instance>
>
> Now I reload this document.  I expect to see that the name John is preserved.  This is because I want the resource attribute to only be evaluated if the instance is empty.  Since it isn't empty, the data in it takes precedence over data that could be obtained from the resource URI.
>
> Note that if I change the above example from using @resource to @src, my expectation is not met because the src attribute overrides the content and gets a new blank copy of the default data.
>
> Since XHTML already has a src attribute, and most current implementations of XForms that don't use XHTML as a host language are document-centric, this says two things:
> 1) there seems to be demand for document-based XForms that should maybe find its way into XHTML
> 2) we really have to fix this for the non-XHTML host languages.
>
> Cheers,
>
> John M. Boyer, Ph.D.
>  Senior Product Architect/Research Scientist
>  Co-Chair, W3C XForms Working Group
>  Workplace, Portal and Collaboration Software
>  IBM Victoria Software Lab
>  E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/
>
>  Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
>
>
>
>
>
>
>  "Mark Birbeck" <mark.birbeck@x-port.net>
> Sent by: w3c-forms-request@w3.org
>
> 09/11/2006 06:21 AM
>
> Please respond to
>  mark.birbeck@x-port.net
>
>
> To John Boyer/CanWest/IBM@IBMCA
>
> cc www-forms@w3.org, www-forms-editor@w3.org
>
> Subject Re: Feedback on 1.1: instance src attribute broken
>
>
>
>
>
>
>
>
>
>
>  Hi John,
>
>  > [...]
>  >
>  > The one place it still appears is on the instance element.  Here I am going
>  > to argue that the semantic of src inherited from HTML is also broken for
>  > instance, so we either need to change it or rename the attribute so we can
>  > change the semantics.
>  >
>  > The problematic behavior is that the content of the instance is *overridden*
>  > by content obtained from a URI given by src.  The behavior should be that
>  > the src URI is used to obtain *default* content for the instance if it is
>  > empty.
>  >
>  > [...]
>
>  I also looked at this issue a while ago, but came to a different conclusion!
>
>  XHTML 2 now allows @src anywhere, and its use is that an attempt is
>  made to load the resource referred to, and if it fails, the content of
>  the element is used as a 'fallback'. This is actually the same
>  behaviour as for <object> with previous versions of XHTML--the new
>  version just generalises this to all elements.
>
>  In my view this would be reasonable behaviour for XForms' instance
>  element, and I think fits the situation you describe--if there is a
>  @src attribute use it, and if the load fails, use the inline content
>  of the instance. See:
>
>    <http://skimstone.x-port.net/node/334>
>
>  for a discussion on this.
>
>  Regards,
>
>  Mark
>
>  --
>  Mark Birbeck
>  CEO
>  x-port.net Ltd.
>
>  e: Mark.Birbeck@x-port.net
>  t: +44 (0) 20 7689 9232
>  w: http://www.formsPlayer.com/
>  b: http://internet-apps.blogspot.com/
>
>  Download our XForms processor from
>  http://www.formsPlayer.com/
>
>
>
>



-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/
Received on Tuesday, 19 September 2006 11:34:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:06 GMT