Re: Feedback on 1.1: instance src attribute broken

Hi Mark,

Actually, I do think that one of us should give the impression that our 
position is 'given' by the XForms spec.

That person is you.  :-)

Although, that really isn't different from what I have been claiming, 
which is also why I sent an email indicating that we need to do a better 
job for non-XHTML host languages. For what it's worth, I already did the 
spec work because I thought this would be a really easy thing to get 
permission to do from the WG and implementation would of course be 
trivial, so if I have to remove the stuff now, I shall have to find a 
corner in which to weep.  <grin/>

Anyway, to be clear, if you look at the description of the instance 
element in Section 3.3.2 
(http://www.w3.org/TR/2006/REC-xforms-20060314/slice3.html#structure-model-instance), 
it says that the special attributes are the linking attributes (src) and 
that "If both an attribute and inline content are provided, the linked 
version takes precedence as described at 4.2.1 The xforms-model-construct 
Event."

Section 4.2.1 
(http://www.w3.org/TR/2006/REC-xforms-20060314/slice4.html#evt-modelConstruct) 
then precisely describes in step 2 of the default processing of 
xforms-model-construct that the result of src if given will be used and 
content will only be used if the src is not given: "If an external source 
for the initial instance data is given, an XPath data model [7 XPath 
Expressions in XForms] is constructed from it; otherwise if inline initial 
instance data is given, that is used instead"

What I'd like to see instead for XForms 1.1 is removal of explicit mention 
of the src attribute, which can be inherited from XHTML and which would of 
course continue to behave as it does today, where content obtained from 
src overrides content that may appear inline.  Instead, I would like to 
see section 3.3.2 say that there is a special attribute called 'resource' 
that provides a URI and "If both an attribute and inline content are 
provided, then the inline content takes precedence as described in Section 
4.2.1."  Then I would like to amend Section 4.2.1 to say that "If inline 
content for the initial instance data is given, then an XPath data model 
is constructed from it; otherwise if an external resource for the initial 
instance data isgiven, that that is used instead..."

Finally, please note that I have directly responded to each of your points 
below...

Best regards,
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: mark.birbeck@gmail.com
09/19/2006 04:34 AM
Please respond to
mark.birbeck@x-port.net


To
John Boyer/CanWest/IBM@IBMCA
cc
w3c-forms-request@w3.org, www-forms@w3.org, www-forms-editor@w3.org
Subject
Re: Feedback on 1.1: instance src attribute broken






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.

JB> Clearly I believe that src trumps inline is supported by the 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'.

JB> Right now the spec clearly supports having a link exception if
JB> the data referenced by src cannot be obtained or is not a well-formed
JB> XML document.

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.

JB> Hopefully it is now clear that I did not say that the semantics of
JB> XForms is that content should take priority.  I only said that this
JB> is what I need *instead of* the current semantic, which can be
JB> obtained using XHTML's src attribute.

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.

JB> I would rather achieve such harmony in XHTML by having XHTML 
contribute
JB> its exact src attribute semantics and make note that other host 
languages
JB> are free to add an attribute like src.  A secondary problem that I am
JB> Trying to solve is that the current behavior of the XForms src is not
JB> identical to XHTML because it has to happen at a specific moment in 
the
JB> default action of xforms-model-construct.  However, because that is so
JB> early in the startup of the XForms processor, it's hard to notice that
JB> the resolution of src by the host XHTML processor may be occuring at 
an
JB> earlier time and may not be doing exactly what the XForms spec does
JB> very clearly call for.

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. 

JB> Yes, this is exactly what I explained is what I wanted to be able to 
do,
JB> except I still do agree that XHTML could have its 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. 

JB> Yes, this is exactly the feature I contend is needed for 
document-centric XForms systems

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, 

JB> Yes, this is exactly what I already described is the current behavior 
of our system.  The problem is that I would like to be able to A) have a 
document centric system that supports save and reload, and B) essentially 
perform application signing by affixing a digital signature over the XForm 
less the content of selected instance elements.  Right now we have to say 
that if you want these two things, then do not use src because when you 
overwrite the src attribute, it breaks the signature, but if you don't 
cover the src attribute then the signature validity does not guarantee 
that the initialization data came from the right place.

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.)

JB> I do agree that this is also a valid use case, but since I am not 
proposing that host languages like XHTML should not support their own src 
attributes, I don't see how I am creating a limitation or back comp 
problem.

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/