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

Re: XForms Basic and Schema Validation

From: David Landwehr <david.landwehr@solidapp.com>
Date: Tue, 09 May 2006 14:25:29 +0200
Message-ID: <44608A39.7030802@solidapp.com>
To: Mark Birbeck <mark.birbeck@x-port.net>
Cc: www-forms@w3.org

Dear Mark,

I asked the XML Schema working group about this since I understood from 
the discussion that datatypes either corresponds to a simple type (I 
believe you wrote that) or to validation of simple content (which I 
believe John wrote). I had my problems reading which one of these 
interpretations were correct and when to get help from Henry.

I think you are a bit unfriendly since I only want this discussion to 
produce a good result. I certainly don't understand that you write 
"although I think the XML Schema spec is also pretty clear on this" when 
you wrote to John "Datatypes *are* simple types!", which from Henry's 
mail is incorrect.

I will leave you to sort it out,
David

Mark Birbeck wrote:
> 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
>> --------------------------------------------
>>
>>
>>     
>
>
>
>   


-- 
--------------------------------------------
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:47:13 GMT

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