RE: WXS types in XForms

Victor,

[I've attached a full demo for anyone interested, since my previous code
snippets didn't include the schema parts.]

> While this is a neat feature, I really don't understand why I 
> should have to include 'xsi:nil="true"' to use it. It's 
> already obvious that the element is empty.

Sure it's obvious that it's empty, that's not the problem -- the problem is
that 'empty' is not on the list of valid values that the schema processor is
looking for. If you say that you want an element to be an integer, you can't
blame the validater if it comes back and says 'empty' is not an integer.


> In addition, I 
> don't want any extra logic to handle the paradox of having 
> nil=true /and/ element contents.

I sympathise. Ideally we would have something like this in XForms:

  <bind nodeset="return-date" nillable="true()"
    type="xsd:date" />

Of course the name could be something else, but the first choice of
'optional' means something slightly different in XForms (although it may be
possible to interpret the definition of 'optional' in such a way that
xsi:nil is included). Anyway, whatever attribute name is used, it would
cause the underlying 'wiring' necessary for XML Schema (or whatever schema
languages are supported in the future) to happen 'magically'.


> Can this attribute be avoided?

Only by doing what you were doing before. But let's be clear that this
requires you to create, for every type that you want to allow to be empty,
*another* type that is both the union of that type, and a zero-length
string. And don't forget that you'll have to do this even for basic types
like integer and date.

If your forms are simple, and you only have one or two datatypes, then this
issue won't be a big deal for you, but if you use a lot of schemas in your
applications then your approach can quickly become a maintenance problem.


> <flame>If not, I'll rather go 
> with the /logical/ solution.</flame>

:) Well, the XML Schema people have been accused of a lot of things, but I
don't think you can say they aren't logical! Some would say they are too
logical ;) ... Anyway the xsi:nil approach was created to solve exactly the
problem under discussion.

I do maintain though, that using 'nillable' is more logical than your
approach. By using 'nillable' we are saying that this element has two
conditions, it either has a value or it doesn't. If it *does* have a value,
it must be a date, or an integer, or whatever -- as defined by its type.
These types can come from a long list of types, and we don't need to create
any new ones. And if it doesn't have a value, this must be indicated by
setting @xsi:nil="true".

However, your approach says that we have an element that must *always* have
a value of a certain type, but it just so happens that one of the values
this type can have is a zero length string. For a start, as I'm sure you are
aware from any database work you have done, that is *not* the same as saying
that the value is 'nil' (or 'null' in the database world). But secondly, it
means that you have to create loads of extra types which are strange
amalgams, like IntegerOrZeroLengthString, DateOrZeroLenghtString,
AddressOrZeroLengthString, etc.

So I would suggest that for now, @xsi:nil is the best solution, but in the
future I would say that we need a new attribute on xf:bind to do all of this
for us.

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/