Re: XForms document versioning

Hello,

i strongly disagree with the idea of allowing the version attribute to 
occur on any element for the following reasons:

one motivation for having the @version attribute which was mentioned in 
this discussion was to give a clear hint to the user which version a 
given document uses. So far so good.

But if the @version is allowed to basically anywhere the user would be 
forced to look at the whole document if a version attribute is there or 
not. It may be even worse if the host language (or languages) also use a 
@version attribute. In this case the user would even have to look closer 
at the namespace the respective @version is in.

That's clearly undermines the purpose of having the @version attribute 
altogether. In my opinion the user should be able to open a document and 
be able to find the @version at a glance and well if it's not there the 
default applies.

The most intuitive locations IMO are the document root element or on the 
default model element.

Of course using the root element shouldn't be enforced (but may be used 
as convention) cause this would imply that the XForms namespace must 
also be defined on the root which might not be the case for dynamically 
assembled documents. Further there already might be another @version 
from the host language so we'll end up with something like this
<root  version="1.0"
    xf:version="1.1"
    xmlns="blablubberbabelfish"
    xmlns:xf="http://www.w3.org/2002/xforms">

Though correct i don't like this from an aesthetic point of view ;)

So i end up with the option of putting the @version on the default 
model. The advantages are obvious:
- a user knows exactly where to look
- a user does not need to 'resolve namespaces'
- by choosing the default model there's no ambiguity regarding recurring 
version attributes on subsequent model elements
- the model element already wears other "meta"-information for which a 
user might look such as @schema and @functions

(break here cause different issue becomes involved)
- a processor knows exactly where to look. Even if everybody currently 
seems to deny that the processor MUST/SHOULD/SHALL use the @version 
attribute i disagree here too. It would be easy for every XForms 1.0 
processor to implement a version checking (even not enforced by the 
Spec) and warn the user that the form might not be processed as 
expected. Even if this is not made a requirement it should be 
implementors freedom to offer this extra. (of course this might pose 
questions with document validation/interoperability which i'll ignore 
here for the moment. It's a pitty that XForms 1.0 missed the train 
regarding the version attribute.)

And if an implementor chooses to support different processing modes for 
1.0 and 1.1 (and upcoming versions) he should be free to do that which 
also offers reliability and predictability. But to allow such a 
'version-switching' the processor has to know where to look first to 
decide which version to execute. Otherwise it would need a two-pass 
reading of the document. On the longer run i fear that not enforcing 
version policies on the processor can create problems with Spec 
modifications that at least partly revert earlier decisions or remove 
language features that have been obsolete or replaced by better mechanisms.

I think these are strong indicators for a defined location of the 
version attribute and do not see what is actually won by allowing it 
anywhere.

Joern





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
>

Received on Thursday, 5 April 2007 21:14:47 UTC