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 19:51:57 +0200
Message-ID: <4460D6BD.4060805@solidapp.com>
To: Mark Birbeck <mark.birbeck@x-port.net>
Cc: www-forms@w3.org, ht@inf.ed.ac.uk

Okay.

Please take a look at this:
<complexType>
      <simpleContent>
        <extension base="integer">
          <xsd:attribute name="test"  type="integer" use="required"/>
        </extension>
      </simpleContent>
    </complexType>

We agree that this is a complex type with simple content. When Henry 
wrote: "The validation semantics of (1) -- (3) are all defined in terms 
of properties of the corresponding datatype.", I toke that as this 
complex type would be regarded as a datatype which can be a mistake from 
my part. Henry, could you clarify if the above type definition would 
qualify as being name a datatype or should it be named a complex type 
with some simple content which is a datatype?

Maybe the term datatype cannot be used in XForms as it is today, e.g. 
maybe datatype is not an actual component you can reference?

Best regards,
David

Mark Birbeck wrote:
> Hi David,
>
> Well, I wasn't being unfriendly--terse, yes--but if John read it like that
> then I do feel bad, and I unreservedly apologise. Also, I was being serious
> that asking Henry was a good idea! But at the same time I was also saying
> that I think the XML Schema spec is quite clear on this (that doesn't mean
> it's easy to read, though).
>
> Anyway, I don't believe that Henry is saying that "datatypes are not simple
> types", and I think the best thing is if I go through his points, as well as
> throw in some points from the XML Schema spec. If you or John still disagree
> with me, at least you can see what parts of the spec I'm referring to, and
> can refute and clarify the references more specifically.
>
> First Henry says:
>
>   In W3C XML Schema, datatypes are to a certain extent an
>   abstraction -- the combination of a lexical space, a value
>   space and a mapping between them -- that is meant to be
>   usable via a range of concrete mechanisms.
>
> As we know, this means that a datatype is a combination of the characters
> that make up a value (the lexical space) and the values that they represent
> (the value space). So in lexical space, a string can be "123" and an integer
> can also be "123", but their *value* spaces are very different, since one is
> 'a string' and one is 'an integer'.
>
> The point that Henry makes about being "to a certain extent an abstraction"
> relates to the fact that the various 'types' in XML Schema are to some
> extent defined in such a way that they can be used independently of specific
> mechanisms. So you have these 'abstract' things which need a mechanism to
> define them. Henry goes on to say that the mechanism for datatypes is the
> "Simple Type Definition":
>
>   W3C XML Schema itself has such a concrete mechanism:
>   the Simple Type Definition component.
>
> So, I think that's clear enough that the term 'datatype' is referring to
> 'simple types'. If this is not convincing enough, then we can also look at
> the scope of the datatypes document:
>
>   This portion of the XML Schema Language discusses datatypes
>   that can be used in an XML Schema. These datatypes can be
>   specified for element content that would be specified as
>   #PCDATA and attribute values of various types in a DTD.
>   It is the intention of this specification that it be usable
>   outside of the context of XML Schemas for a wide range of
>   other XML-related activities such as [XSL] and [RDF Schema].
>   [1]
>
> Henry then goes on to look at where these simple types can be used. The
> first two are quite easy, so let's deal with them first:
>
>  This in turn may appear and function in three contexts:
>   1) As the {type definition} of an Attribute Declaration;
>   2) As the {type definition} of an Element Declaration;
>
> Henry is pointing out that an attribute or an element can contain simple
> type content. I should say though, that in the second case this should be
> qualified to say that it is only applicable when the element has no further
> elements as children. The XML Schema spec puts it like this:
>
>   A simple type definition is a set of constraints on strings and
>   information about the values they encode, applicable to the
>   .normalized value. of an attribute information item or of an
>   element information item with no element children. Informally,
>   it applies to the values of attributes and the text-only content
>   of elements. [2]
>
> Whilst we're here, it's worth pointing out that *by definition* simple types
> are created by restricting some other simple type, which means that to get
> you started XML Schema must provide a set of 'built-in' simple types. These
> are referred to as datatypes, as the previously quoted section goes on to
> say:
>
>   Each simple type definition, whether built-in (that is, defined
>   in [XML Schemas: Datatypes]) or user-defined, is a .restriction.
>   of some particular simple .base type definition..
>
> Anyway, we've established that simple types are used to set the *content* of
> attributes as well as the *content* of elements (provided that they can have
> content, and also have no child elements). But in XML Schema you need more
> than just the values that go *inside* the attributes and elements, you need
> to specify the relationship between elements and attributes. As we know,
> this relationship is defined using 'complex types', but there are two types
> of complex types, those which have 'simple content' and those which have
> 'complex content'.
>
> To illustrate this, let's return to the point that Henry was making in his
> second bullet, and we should be able to see where the notions of 'simple
> content' and 'complex content' come from. Recall that we can use simple
> types in elements that have no children, and I'll reuse the example of such
> a set-up I gave in a previous post:
>
>   <length unit="cm">25</length>
>
> Here we are using simple types to define the contents of @unit as well as
> the contents of <length>. Compare that mark-up to a structure like this:
>
>   <length>
>     <value>25</value>
>     <unit>cm</unit>
>   </length>
>
> Here simple types are used for the content of <unit> and <value>, but
> crucially, the content of <length> is other elements.
>
> In both of these examples we have a complex type, but in the first example
> the 'content type' is called 'simple content' and in the second example the
> 'content type' is called 'complex content'. According to the spec:
>
>   A complex type definition is a set of attribute declarations and a
>   content type, applicable to the [attributes] and [children] of an
>   element information item respectively. [3]
>
> In other words, when you define a complex type you need two things; a whole
> bunch of attribute declarations, and the definition of the content type. The
> spec goes on to describe 'content type':
>
>   The content type may require the [children] to contain neither
>   element nor character information items (that is, to be empty),
>   to be a string which belongs to a particular simple type or to
>   contain a sequence of element information items which conforms
>   to a particular model group, with or without character
>   information items as well.
>
> This simply means that the content of a complex type can be:
>
>   * empty;
>   * a simple type;
>   * child elements (and perhaps mixed content).
>
> This is what Henry is referring to in his 3rd point--that a simple type may
> appear as *part of* the definition of a complex type, when the complex type
> specifies that the element only has a string of text for its content:
>
>   3) As the {content type} of a Complex Type Definition (which
>      itself will typically be the {type definition} of an Element
>      Declaration).
>
> However, using a simple type in this way would not result in another simple
> type--i.e., a pattern for expressing the *contents* of an attribute or
> element--it would result in the definition of a complex type--i.e., a
> pattern for an element with text content, and possibly some attributes.
>
> So, to recap the terminology, using the examples I gave before:
>
>   <length unit="cm">25</length>
>
>   <length>
>     <value>25</value>
>     <unit>cm</unit>
>   </length>
>
> 1. Both of these would require a Complex Type Definition to
>    describe them.
>
> 2. The first example is a complex type with 'simple content'.
>
> 3. The second is a complex type with 'complex content'.
>
> 4. In the first, the contents of <length> and @unit are
>    simple types.
>
> 5. In the second the contents of <unit> and <value> are also
>    simple types.
>
>
> I hope this clarifies the terminology that we should be using, and that in
> both the XForms Basic spec and John's email terms were not being used
> correctly.
>
> I won't restate my position on the XForms Basic spec since this is more
> about trying to clarify the terms used in our discussion.
>
> Regards,
>
> Mark
>
> [1] http://www.w3.org/TR/xmlschema-2/#scope
>
> [2] 2.2.1.2 Simple Type Definition
>     XML Schema Part 1: Structures Second Edition
>     http://www.w3.org/TR/xmlschema-1/
>
> [3] 2.2.1.3 Complex Type Definition
>     XML Schema Part 1: Structures Second Edition
>     http://www.w3.org/TR/xmlschema-1/
>
>
> 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 13:25
>> To: Mark Birbeck
>> Cc: www-forms@w3.org
>> Subject: Re: XForms Basic and Schema Validation
>>
>> 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
>> --------------------------------------------
>>
>>
>>     
>
>
>
>   


-- 
--------------------------------------------
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 17:52:16 GMT

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