RE: XForms Basic and Schema Validation

Hi Mark,

The sentence says that all Schema datatypes other than the ones listed are 
to be treated as string, not all built-in schema datatypes.

"In my opinion" This is why any attempt to assign a datatype other than 
the ones listed should be regarded as string.

At a higher level, the purpose of basic was exactly so that basic 
processors did not have to do a very smart schema engine.
This goal does not seem to be achieved if basic processors have to be 
smart enough to read the schema definitions to figure
out that the datatype is undefined. 

"In my opinion" An implementation should be able to write lexical 
analyzers for just those 26 given datatypes, and apply the write analyzer 
for
the given datatype and otherwise it should be able to pretend that the 
type assignment refers to string.

This is my interpretation of the third bullet point.  It seems to be a 
proper subset of the second bullet point, which says a processor may
only implement validation of simple types.

If something other than this was intended, then, yes, the wording of basic 
needs work to clarify that the third bullet point is referring to 
built-in types only.  And then, yes, this would introduce the problem of 
basic seeing a custom type it doesn't recognize and producing
an error where a full implementation would not.  However, we would still 
need to solve that problem, and a good solution would be to
say that basic processors are not like full processors in that they treat 
unrecognized datatypes as string.  Then ship Basic!

Cheers,
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/04/2006 04:31 AM

To
<www-forms@w3.org>
cc

Subject
RE: XForms Basic and Schema Validation







Hi Allan,

> -----Original Message-----
> From: www-forms-request@w3.org 
> [mailto:www-forms-request@w3.org] On Behalf Of Allan Beaufour
> Sent: 04 May 2006 10:28
> To: Mark Birbeck
> Cc: www-forms@w3.org
> Subject: Re: XForms Basic and Schema Validation
> 
> 
> On 5/4/06, Mark Birbeck <mark.birbeck@x-port.net> wrote:
> > However, one thing is certain--the error (using an undefined type) 
> > cannot be ignored. On the telecon earlier today, people kept saying 
> > that if a non-existent type was referenced then the 
> processor should 
> > interpret the node as being of type xsd:string; I don't see 
> how this 
> > interpretation was arrived at, and it's certainly not in 
> the specification.
> 
> It is in Basic is it not:
> "XForms Basic Profile processors may treat XML Schema 
> datatypes other than the following as xsd:string: [... list of types]"
> [http://www.w3.org/TR/xforms-basic/#id2606183]
> 
> --
> ... Allan

No...I think that's something different. I read that to mean that all XML
Schema built-in types *other than* those listed can be treated as
xsd:string. In other words, you can treat the following XML Schema 
datatypes
as strings:

  * duration
  * hexBinary
  * float
  * double
  * QName
  * NOTATION
  * normalizedString
  * token
  * language
  * Name
  * NCName
  * NMTOKEN
  * NMTOKENS
  * ID
  * IDREF
  * IDREFS
  * ENTITY
  * ENTITIES

But these are 'known' types--it's no more than saying that if an author
uses:

  <bind nodeset="a" type="xsd:QName" />

an implementer of XForms Basic need not actually check for a QName, but 
can
just check as for xsd:string.

But this doesn't mean that using an unknown type is ok:

  <bind nodeset="a" type="xsd:doodle" />

This should still be an error of some sort, in both Full and Basic.

Regards,

Mark


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/