W3C home > Mailing lists > Public > www-forms@w3.org > April 2007

Re: XForms document versioning

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 5 Apr 2007 11:15:38 +0100
Message-ID: <640dd5060704050315l4b0cebe7p45fcb3acbe9e06a9@mail.gmail.com>
To: "Aaron Reed" <aaronr@us.ibm.com>
Cc: www-forms@w3.org

Hi Aaron,

Everything you say is true! :)

However, the global version attribute I am suggesting is basically an
indicator to authors, rather than processors, since I have doubts
about how easy it is to enforce versioning at the level of the

The reason I'm not sure we can make versioning work at the porcessor
level is because we didn't put it in from the beginning, in XForms
1.0). The good thing about the XSLT version attribute is that it was
there from the start, so even a 1.0 processor must check the attribute
value. This means that every single XSLT 1.0 processor out there can
bail when it sees a stylesheet that is intended for a newer version of

That's not the situation we're in, and I'll give some examples of how
it can cause problems.

On xf:message in version 1.0 a value is required for @level. But in
XForms 1.1 there is a default value for @level, of "modal", so the
attribute can be omitted. If we write a form that makes use of this
facility, what will happen to it when it arrives at a 1.0 processor?
The message will probably not be displayed.

Similarly, in XForms 1.1 we have the new resource element and
attribute on submission. Anyone writing new forms going forward will
most likely use @resource instead of @action on submission, even on
forms that don't need the new features, since it keeps things nice and
consistent. But once again, what will happen this form when it arrives
at a 1.0 processor? Not a lot when the submission is triggered, since
there will be no @action.

I could go on--there is improved behaviour in insert if the nodeset is
empty, etc., etc. In other words, there are plenty of situations where
1.1 mark-up will be interpreted differently in 1.0.

Now, I'm happy to agree that any serious application developer who is
using XForms a lot will need to be aware of issues like this, and code
appropriately if they want their forms to work on both 1.1 and 1.0
processors; having a @level on all messages, for example, is no big
deal. But where I am most concerned is in relation to the brand new
author who cuts and pastes a nice looking example from a web-site,
only to find that it doesn't work in their chosen processor. The
ensuing exchanges on our list as we try to establish exactly why it
doesn't work will be painful. ;)

So that's what lies behind my suggestion; I'm making a distinction
between mandating some behaviour for a processor, versus providing
help to authors. If we can solve both then even better! But I think to
do that we need to add the version attribute to XForms 1.0...which I'm
certainly all in favour of, but I don't know what other implementers

(The only other alternative is to keep making changes to XForms 1.0
that make it more 1.1-like...replacing @action with @resource,
allowing @level to have a default value, etc. But that just doesn't
seem practical.)



On 05/04/07, Aaron Reed <aaronr@us.ibm.com> wrote:
> Hi Mark,
> So any host language element could have this attribute on it?  What if
> there were multiple host language elements with xf:version and some of
> the version numbers were different?  This could certainly happen if we
> ever get the 'include' type functionality in XForms and we have
> different sections of the form coming from different documents.  And I
> assume xf:model's @version would win if the host-language element's and
> model element's @version differed?  Or is this meant to replace model's
> @version?  I could see them being different values because a 1.0
> processor can't honor the model's @version until it supports ALL of X.Y
> (whatever the value of @version is).  So the version on the
> host-language element could say 1.1 but there be no version on the model
> because someone could write a 1.1-level form using only the 1.1 pieces
> that their specific processor supports. .  This would also be true if
> the form author created some XBL to build up the processor's
> functionality to 1.1 level for things the author wants to use but the
> processor doesn't support, yet.
> Having said all of that, I have no problem with the idea, just seems
> that it'll have the same drawbacks as model's @version where the version
> specified in the form may not match what the processor is capable of.
> --Aaron
> Mark Birbeck wrote:
> >
> > Hello,
> >
> > I'd like to suggest that we have a version attribute that can be used
> > on any element in a host language. This would therefore be a global
> > attribute in the XForms namespace, and might be used as follows:
> >
> >  <html xf:version="1.1">
> >    ...
> >  </html>
> >
> > My feeling is that this attribute is less about enforcing behaviour of
> > processors, and more about providing a clear indication to authors
> > which type of document they are dealing with.
> >
> > For example, if a form contains a submission that uses the new
> > xf:resource attribute or element, it may not be immediately obvious to
> > a new author as they start to learn XForms, that this is not supported
> > in all processors. Rather than having a flurry of emails on one or
> > other list saying that some example doesn't work, I think we should
> > encourage authors to indicate what standard is being used by a form.
> >
> > Regards,
> >
> > Mark
> >

  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.
Received on Thursday, 5 April 2007 10:15:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:20 UTC