Re: XForms Basic and Schema Validation

Hi,

I took the liberty to ask the XML Schema WG what the term datatype are 
meant to be. Henry gave the very good answer here:
http://lists.w3.org/Archives/Public/xmlschema-dev/2006May/0008.html

I hope this can help this discussion which I feel is very important for 
XForms.

Best regards,
David


Mark Birbeck wrote:
> Hi John,
>
> 1. Simple types and simple content are two different things.
> 2. Datatypes *are* simple types!
>  
> 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/
>
>  
>
> ________________________________
>
> From: John Boyer [mailto:boyerj@ca.ibm.com] 
> Sent: 08 May 2006 22:32
> To: Mark Birbeck
> Cc: www-forms@w3.org; www-forms-request@w3.org
> Subject: RE: XForms Basic and Schema Validation
>
>
>
> 	
> 	Hi Mark, 
> 	
> 	The notion of datatype is orthogonal to simple vs. complex type. 
> 	
> 	Section 2.2.1.3 of Schema Part 1 is clear in defining the fact that
> you can have a complex type with simple content.   
> 	And you can datatype validate the simple content of a complex type. 
> 	
> 	>I agree if you were using the term datatype in its proper sense.
> But
> 	>datatypes are simple types, not complex ones, so I disagree, since
> it sounds
> 	>like you are using it to cover complex types. 
> 	
> 	I am using datatype in its proper sense, which is also what the spec
> is doing, I believe. 
> 	Datatypes are not simple types.  They are descriptions of string
> validations, which can 
> 	be used to validate content of both simple and complex types. 
> 	
> 	>Well...firstly it actually says "XML Schema datatypes" which to me
> means
> 	>'the datatypes from XML Schema Part 2'. In other words, it doesn't
> deal with
> 	>other types defined by an author.
> 	
> 	Sorry, but you are misreading "XML Schema datatypes" as "XML Schema
> built-in datatypes". 
> 	If XForms Basic had intended to refer to the built-in datatypes, it
> should have used 
> 	that term.  But XML Schema Part 2 is about providing the machinery
> for defining ones own 
> 	datatypes. It then uses that machinery to create a number of
> built-in datatypes.  Note 
> 	that the built-in datatypes can be used in complex types that define
> simple content.
> 	
> 	So, we are left with the fact that XForms 1.0 was designed to
> address the *main* use 
> 	case for validation, which is user input validation.  That's why the
> spec contains 
> 	language associating the type MIP with schema datatype. If anything
> more than that works 
> 	for an implementation, it seems to me to be a bit of a bonus for
> that implementation. 
> 	
> 	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/08/2006 05:33 AM 
>
> 		
> 		To
> 		<www-forms@w3.org> 
> 		cc
> 		
> 		Subject
> 		RE: XForms Basic and Schema Validation
>
> 		
>
>
>
>
> 	
> 	Hi John,
> 	
> 	Here's an 'executive summary' of the points that I'll provide
> explanation
> 	for, inline below:
> 	
> 	 One problem with XForms Basic as defined is that it doesn't
> 	 explain how the 'downgrading' of a complex type should take
> 	 place. The second bullet (in XForms Basic) provides for the
> 	 *possibility* of this downgrading by saying that a processor
> 	 "may" choose to only support simple types, but nowhere is it
> 	 explained what it would mean in practice. (And in reply to
> 	 your and Raman's view that the third bullet deals with this,
> 	 I'm afraid it doesn't--it deals with *datatypes*, which are
> 	 simple types.)
> 	
> 	
> 	>                 The sentence says that all Schema datatypes other
> than the
> 	> ones listed are to be treated as string, not all built-in schema
> 	> datatypes.
> 	
> 	Well...firstly it actually says "XML Schema datatypes" which to me
> means
> 	'the datatypes from XML Schema Part 2'. In other words, it doesn't
> deal with
> 	other types defined by an author.
> 	
> 	But even if you ignore the "XML Schema" bit, the term used is
> 'datatype'
> 	which has a very specific meaning; to infer that this sentence
> suggests that
> 	any *complex* type that the author has defined should also be
> converted to
> 	xs:string, would require you to include 'complex types' within the
> 	definition of 'datatypes' which--as you rightly say in a discussion
> with
> 	Allan on that very subject-- is incorrect. :)
> 	
> 	I suppose you could say that using the word 'datatype' was a
> mistake, and
> 	what was actually intended was the more general term 'type
> definition'; but
> 	that makes things worse, since this term includes both simple and
> complex
> 	types, so the third bullet would actually be saying that any type
> definition
> 	other than those listed would be xs:strings--obviously not what is
> intended.
> 	
> 	So my suggestion is for the WG to stop trying to rush this out, and
> properly
> 	resolve the issue of how complex types behave. (The spec hasn't
> moved for
> 	about 2 1/2 years, I think another week isn't going to hurt.)
> 	
> 	As it happens, I don't really see anything wrong with the third
> bullet in
> 	relation to its stated subject matter which is datatypes. All it
> says is
> 	that for some datatypes you don't need to provide any special
> regular
> 	expressions if you are doing a 'subset processor'.
> 	
> 	
> 	However, the big thing that *is* glaringly missing is the bridge
> from the
> 	goal that has been described (of not requiring an XForms Basic
> processor to
> 	have a full XML Schema implementation) and the reality of the prose;
> we need
> 	something very clear that explains how a Basic processor should
> proceed if
> 	it is going to 'downgrade' complex types.
> 	
> 	In working through some kind of proposal for this, it seems to me
> that
> 	mapping to xs:string may not actually be the best solution. I'll try
> to
> 	explain, and people can say what they think.
> 	
> 	
> 	Looking at the entirety of XML Schema, I would say that what we're
> after is
> 	the following behaviour for a 'subset' schema processor:
> 	
> 	 * a reference to any undefined type is an error;
> 	
> 	 * any *datatype* that is not in the list in
> 	   bullet 3 has a regular expression that is
> 	   equivalent to xs:string;
> 	
> 	 * any *simple* type is processed as normal (i.e.,
> 	   as it would be in Full);
> 	
> 	 * any *complex* type is processed as if it were
> 	   a simple type, with all element and attribute
> 	   definitions ignored.
> 	
> 	The first point may or may not be implicit in our schema processing
> anyway,
> 	but I think it needs some clarification. However, we can ignore it
> for this
> 	discussion since it should really be defined in XForms Full anyway.
> 	
> 	The second point, on the behaviour of datatypes, is already given by
> bullet
> 	3 in the spec, so we need do nothing here either.
> 	
> 	Similarly, on the third point, the behaviour of simple types is
> already
> 	given by bullet 2 in the spec, and although it might benefit from
> 	clarification, it's at least there in part.
> 	
> 	So all we need is an extra bullet that clarifies how complex types
> are
> 	converted, and here I'm proposing *not* that they are automatically
> 	converted to strings--which is the current proposal--but that the
> 	*structural* features are ignored.
> 	
> 	
> 	The following example is given in the XML Schema specification of
> how an
> 	element 'width' can have a value which is a non-negative integer, as
> well as
> 	an attribute which indicates the unit of that non-negative integer:
> 	
> 	 <xs:complexType name="length1">
> 	   <xs:simpleContent>
> 	     <xs:extension base="xs:nonNegativeInteger">
> 	       <xs:attribute name="unit" type="xs:NMTOKEN"/>
> 	     </xs:extension>
> 	   </xs:simpleContent>
> 	 </xs:complexType>
> 	
> 	 <xs:element name="width" type="length1" />
> 	
> 	 <width unit="cm">25</width>
> 	
> 	As far as I can see a processor that can handle simple types (which
> all
> 	Basic processors will do) can process the example I just gave, as
> easily as
> 	they can process the following:
> 	
> 	 <xs:simpleType name="length1">
> 	   <xs:restriction base="xs:nonNegativeInteger" />
> 	 </xs:simpleType>
> 	
> 	By doing this, at very little cost we reduce the gap between XForms
> Basic
> 	and XForms Full. (From the XML Schema terminology point of view,
> what I'm
> 	saying is that since:
> 	
> 	 simple content = simple type + attributes
> 	
> 	we can 'remove' the attributes and still make use of the simple type
> 	definition, rather than just saying 'string'.)
> 	
> 	
> 	>                 "In my opinion" This is why any attempt to assign
> a datatype
> 	> other than the ones listed should be regarded as string.
> 	
> 	I agree if you were using the term datatype in its proper sense. But
> 	datatypes are simple types, not complex ones, so I disagree, since
> it sounds
> 	like you are using it to cover complex types.
> 	
> 	
> 	>                 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.
> 	
> 	That's a slightly different issue. The processor has to process the
> XML
> 	Schema mark-up anyway, in order to find the simple types. Spotting
> undefined
> 	types should be easy.
> 	
> 	
> 	>                 "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.
> 	
> 	I understand the goal, and explained that in my post...but I still
> don't
> 	like the fact that you can't predict what the platform you are
> running on
> 	will do. I really don't think it's a good idea to allow Basic to
> 'maybe' do
> 	this or 'maybe' do that. I would prefer to see the behaviour defined
> clearly
> 	and then for us to say that this is how a Basic processor will
> behave.
> 	However, I'm happy to leave that issue to one side whilst we
> actually sort
> 	out the lack of clarity on the behaviour.
> 	
> 	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/
> 	
> 	
> 	
> 	
> 	
>
>
>
>
>   


-- 
--------------------------------------------
David Landwehr (david.landwehr@solidapp.com)
Chief Executive Officer, SolidApp
Web: http://www.solidapp.com
Office: +45 48268212
Mobile: +45 24275518
--------------------------------------------

Received on Tuesday, 9 May 2006 09:37:46 UTC