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