W3C home > Mailing lists > Public > www-forms@w3.org > May 2006

RE: XForms Basic and Schema Validation

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 10 May 2006 11:15:27 +0100
To: <www-forms@w3.org>
Cc: <ht@inf.ed.ac.uk>
Message-ID: <015801c6741a$a902c2e0$7e01a8c0@Jan>

John,

Executive summary--for those who don't want to wade through this debate yet
again!:

  To put it a different way, it's fine to talk about datatypes
  if that is *all* you mean (i.e., xs:integer, etc.) but if you
  are talking about what the author can *create* then you need
  to talk about simple types, since the only mechanism that an
  author has to create a datatype [in XForms] is the use of
  XML Schema, i.e., xs:simpleType, etc.


> I believe that Mark's contention that the term datatype is
> perhaps being misused in the XForms spec is likely due to
> the incorrect conclusion that what a datatype is and how it
> is expressed were one and the same thing.

No...I'm pretty clear on that, but I would clarify that all of my discussion
has been about XForms Basic, plus reference to points made on this list in
relation to that. There were actually two separate discussions--the first
concerned bind/@type and the second related to XForms Basic, and I haven't
actually said anything on the first discussion, because I wanted to focus on
the XForms Basic issues.


> The use of the term datatype is deliberate because the most
> important use case for XForms 1.0 that has been discussed at
> many face to face meetings is vcharacter data validation,
> which corresponds to direct user input.

So are you saying that some flavours of XForms processor need not support
XML Schema at all? We know that a standard can support the XML Schema
datatypes (xs:integer, xs:date, etc.) without making use of XML Schema
constructs (xs:simpleType, xs:element, etc.), so it's possible that what the
authors of XForms Basic wanted to say is that any xs:schema element can be
completely ignored, and all that needs to be understood are things like
this:

  <bind nodeset="d" type="xs:date" />

In addition, since XForms Basic need only process certain datatypes, the
following two statements are equivalent:

  <bind nodeset="q" type="xs:QName" />

  <bind nodeset="q" type="xs:string" />

This would be ideal for an XForms Tiny implementation, and it could even be
that this is what was intended in XForms Basic. If that *is* what is
intended in XForms Basic then the second bullet needs dramatically reworking
to say that we are only making use of the (abstract) datatypes from XML
Schema (in just the same way that XSLT and RDF do):

  XForms Basic Profile processors may implement a subset of an
  XML Schema processor [XML Schema part 1], [XML Schema part 2],
  requiring only what is necessary to process the attribute
  xsi:type on instance data for simpleTypes only and the type
  model item property for simpleTypes only.

This needs reworking because as it stands it very much implies that an
XForms Basic processor supports a subset of XML Schema that allows authors
to define new simple types (i.e., supports xs:simpleType). That in turn
implies that the xs:schema element can't be ignored, and if it's not
ignored, we need to spell out exactly how it should be processed in relation
to complex types.

So, although this 'ignore xs:schema' processor might be a useful 'third
level'--'very lite'--version of XForms, I don't think this is what you're
getting at, and is probably not the intent of XForms Basic.


You went on to say in your post:

> So, yes, in answer to your [David's] final question, what I
> have been saying in numerous posts is that the type MIP of
> XForms is for associating a datatype and therefore corresponds
> to datatype validation even if the datatype association was
> made based on a datatype obtained from a complex type.

This puts me right back where I was before, I'm afraid. Firstly, the
assumption you are deriving is really not clear from the spec, and secondly,
there is still a confusing use of 'datatype'.

My posts--following from my action to look at XForms Basic--have all been
about looking at the assertion that was floating around on both the list and
the call, that the whole process of 'ignoring' complex types within XForms
Basic was 'covered' by the XForms Basic statement:

  XForms Basic Profile processors may treat XML Schema
  datatypes other than the following as xsd:string:

A number of people implied that it was this 'rule' that told us everything
we needed to know about treating complex types as strings. My assertion was
that the reason people thought this was probably because the term 'datatype'
was being interpreted as though it was actually the more general XML Schema
term 'type definition'.

You put forward an alternative interpretation in your other post [1], John,
that in this context 'datatype' *was* used correctly--as it is in
bind/@type--but we should interpret this to mean not just a 'datatype', but:

  a datatype...perhaps derived from looking at a complex
  type with simple content (provided of course that it is
  simple content and not complex content...or nillable.

That's a lot to read into the word "datatype"!

But my problem is that even if we said that this statement could be read
into this, the whole use of 'datatype' still remains confused; datatypes are
abstract things, intended for use in standards that don't support XML
Schema, such as RDF and XSLT. If we are saying that XForms Basic does *not*
support XML Schema then fine, let's spell that out, and make use of the XML
Schema datatypes from Part 2.

But XForms Full *does* support XML Schema, so although we obviously do
support 'datatypes' indirectly (since XML Schema does) we also, more
'tangibly', support simple types.

To put it a different way, it's fine to talk about datatypes if that is
*all* you mean (i.e., xs:integer, etc.) but if you are talking about what
the author can *create* then you need to talk about simple types, since the
only mechanism that an author has to create a datatype is the use of XML
Schema, i.e., xs:simpleType, etc.

In my view, this needs sorting out at least in XForms Basic, and preferably
in XForms Full, too.

Regards,

Mark


[1] http://lists.w3.org/Archives/Public/www-forms/2006May/0075.html
[2] http://lists.w3.org/Archives/Public/www-forms/2006May/0054.html

Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/
Received on Wednesday, 10 May 2006 10:16:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:04 GMT