RE: XForms Basic and Schema Validation

Hi Mark,

To be clear, my back story on this is one of relative surprise at the 
recent suggestion that
one could put a complex type at all into an XForms type MIP in XForms 
full.

My own posts up to now have been about my own attempt to rationalize what 
I believe
to be the unreasonable claim that because we said type "associates" a 
datatype and
the legal values "represent" datatypes, then somehow we get complex types 
out of
that.  I think it's unreasonable to need one, but I'm game for a 
clarification erratum that
says type "attaches" a datatype to a "simple content node" and the legal 
values are
those that "are" datatypes.

At which point our positions become equivalent, i.e. type is for 
simpleType.  That *is*
what I believed until recently where folks like yourself claimed that 
because Xforms full
supports schema then type refers to anything and that datatype was badly 
used.

This I cannot accept as more than an affront to the first edition editors 
and the author
of the type material in XForms 1.0.  The use and citations of datatype and 
associated 
concepts are quite deliberate, and it is clear to me that complexType was 
not the intended
use of the XForms type MIP.  I agree that it is *very* creative reading of 
XForms 1.0
to suggest otherwise.

So, if you are truly back from the dark side of trying to stuff 
complexType into the 
XForms type MIP, then great because I could use the company as I need to 
do other things 
besides write emails about this.

Moreover, a proper reading of XForms full, in which only datatypes (via 
simpleType references)
are allowed in the XForms *full* version of the type MIP means that the 
solution for XForms
basic can be exactly the one I've previously indicates.  There is no need 
to pull basic
from CR back to last call.  As written, a basic interpreter need only 
understand 20-something
specific references to certain built-in datatypes, and any other type 
assignment *to a
simple content node* is just a string.  Basic is *supposed* to declare 
valid some things that
full would not.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: www-forms-request@w3.org
05/10/2006 03:15 AM

To
<www-forms@w3.org>
cc
<ht@inf.ed.ac.uk>
Subject
RE: XForms Basic and Schema Validation







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/