RE: XForms Basic and Schema Validation

David,

Great...although I think the XML Schema spec is also pretty clear on this.

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/


> -----Original Message-----
> From: David Landwehr [mailto:david.landwehr@solidapp.com] 
> Sent: 09 May 2006 10:38
> To: Mark Birbeck
> Cc: www-forms@w3.org
> Subject: 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 12:06:23 UTC