- From: David Landwehr <david.landwehr@solidapp.com>
- Date: Tue, 09 May 2006 14:25:29 +0200
- 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 UTC