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:55:28 UTC