- From: Mark Birbeck <mark.birbeck@x-port.net>
- Date: Wed, 10 May 2006 11:15:27 +0100
- To: <www-forms@w3.org>
- Cc: <ht@inf.ed.ac.uk>
John, Executive summary--for those who don't want to wade through this debate yet again!: To put it a different way, it's fine to talk about datatypes if that is *all* you mean (i.e., xs:integer, etc.) but if you are talking about what the author can *create* then you need to talk about simple types, since the only mechanism that an author has to create a datatype [in XForms] is the use of XML Schema, i.e., xs:simpleType, etc. > I believe that Mark's contention that the term datatype is > perhaps being misused in the XForms spec is likely due to > the incorrect conclusion that what a datatype is and how it > is expressed were one and the same thing. No...I'm pretty clear on that, but I would clarify that all of my discussion has been about XForms Basic, plus reference to points made on this list in relation to that. There were actually two separate discussions--the first concerned bind/@type and the second related to XForms Basic, and I haven't actually said anything on the first discussion, because I wanted to focus on the XForms Basic issues. > The use of the term datatype is deliberate because the most > important use case for XForms 1.0 that has been discussed at > many face to face meetings is vcharacter data validation, > which corresponds to direct user input. So are you saying that some flavours of XForms processor need not support XML Schema at all? We know that a standard can support the XML Schema datatypes (xs:integer, xs:date, etc.) without making use of XML Schema constructs (xs:simpleType, xs:element, etc.), so it's possible that what the authors of XForms Basic wanted to say is that any xs:schema element can be completely ignored, and all that needs to be understood are things like this: <bind nodeset="d" type="xs:date" /> In addition, since XForms Basic need only process certain datatypes, the following two statements are equivalent: <bind nodeset="q" type="xs:QName" /> <bind nodeset="q" type="xs:string" /> This would be ideal for an XForms Tiny implementation, and it could even be that this is what was intended in XForms Basic. If that *is* what is intended in XForms Basic then the second bullet needs dramatically reworking to say that we are only making use of the (abstract) datatypes from XML Schema (in just the same way that XSLT and RDF do): XForms Basic Profile processors may implement a subset of an XML Schema processor [XML Schema part 1], [XML Schema part 2], requiring only what is necessary to process the attribute xsi:type on instance data for simpleTypes only and the type model item property for simpleTypes only. This needs reworking because as it stands it very much implies that an XForms Basic processor supports a subset of XML Schema that allows authors to define new simple types (i.e., supports xs:simpleType). That in turn implies that the xs:schema element can't be ignored, and if it's not ignored, we need to spell out exactly how it should be processed in relation to complex types. So, although this 'ignore xs:schema' processor might be a useful 'third level'--'very lite'--version of XForms, I don't think this is what you're getting at, and is probably not the intent of XForms Basic. You went on to say in your post: > So, yes, in answer to your [David's] final question, what I > have been saying in numerous posts is that the type MIP of > XForms is for associating a datatype and therefore corresponds > to datatype validation even if the datatype association was > made based on a datatype obtained from a complex type. This puts me right back where I was before, I'm afraid. Firstly, the assumption you are deriving is really not clear from the spec, and secondly, there is still a confusing use of 'datatype'. My posts--following from my action to look at XForms Basic--have all been about looking at the assertion that was floating around on both the list and the call, that the whole process of 'ignoring' complex types within XForms Basic was 'covered' by the XForms Basic statement: XForms Basic Profile processors may treat XML Schema datatypes other than the following as xsd:string: A number of people implied that it was this 'rule' that told us everything we needed to know about treating complex types as strings. My assertion was that the reason people thought this was probably because the term 'datatype' was being interpreted as though it was actually the more general XML Schema term 'type definition'. You put forward an alternative interpretation in your other post [1], John, that in this context 'datatype' *was* used correctly--as it is in bind/@type--but we should interpret this to mean not just a 'datatype', but: a datatype...perhaps derived from looking at a complex type with simple content (provided of course that it is simple content and not complex content...or nillable. That's a lot to read into the word "datatype"! But my problem is that even if we said that this statement could be read into this, the whole use of 'datatype' still remains confused; datatypes are abstract things, intended for use in standards that don't support XML Schema, such as RDF and XSLT. If we are saying that XForms Basic does *not* support XML Schema then fine, let's spell that out, and make use of the XML Schema datatypes from Part 2. But XForms Full *does* support XML Schema, so although we obviously do support 'datatypes' indirectly (since XML Schema does) we also, more 'tangibly', support simple types. To put it a different way, it's fine to talk about datatypes if that is *all* you mean (i.e., xs:integer, etc.) but if you are talking about what the author can *create* then you need to talk about simple types, since the only mechanism that an author has to create a datatype is the use of XML Schema, i.e., xs:simpleType, etc. In my view, this needs sorting out at least in XForms Basic, and preferably in XForms Full, too. Regards, Mark [1] http://lists.w3.org/Archives/Public/www-forms/2006May/0075.html [2] http://lists.w3.org/Archives/Public/www-forms/2006May/0054.html 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/
Received on Wednesday, 10 May 2006 10:16:53 UTC