- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 9 May 2006 18:18:21 -0400
- To: "Mark Birbeck" <mark.birbeck@x-port.net>
- Cc: www-forms@w3.org, www-forms-request@w3.org
- Message-ID: <OFE6407E5D.C43A0725-ON88257169.005BAC5B-88257169.007A8805@ca.ibm.com>
Hi Mark,
Took no offense with your shorter emails.
Some of what you wrote below has allowed me to figure out, I think, what
is the disconnect between our positions.
In short, I am talking about what a datatype is and therefore how it is
used, whereas you appear to be talking
about how a specific datatype is declared or expressed in markup. The
difference is that the latter is not
appropriate for figuring out the XForms type MIP.
A datatype is not a simple type. A datatype is always expressed by a
simple type.
The difference is very important, and fusing the two things together is
what is causing, well, some confusion.
Schema Part 2 [1] defines the *notion* of datatype as an abstract
mechanism that is related to the validation
of character data [2, 3]. One can *express* a datatype using a Simple
Type Definition [4].
But the fact that a datatype is *expressed* by a simple type does not, in
any way, mean it cannot be *used*
in a complex type definition. A datatype *is* just a 3-tuple that defines
some character data validation, and
so it *can* be used in complex type declarations.
The exact definition of complex type appears in Schema Part 1 at [5],
specifically in subsection 2.2.1.3.
A complex type can be defined to have simple content, but it is an
extension of a simple type because
the element whose type is being defined also must have attributes. Once
this complex type is defined,
it can be used in other complex types that define restrictions. The net
of this is that you can have complex
types whose base schema components are simple types or complex types, and
in both cases the content
model for the complex type can still be simple content.
With regard to XForms, the description of a type MIP says that it
*associates* a datatype with a node.
It does *not* say that the type MIP is restricted from referencing complex
types. It only says that it
associates the *datatype* from the referenced type with the instance node.
Since only the datatype is
associated, validation is based on the definition of datatype validation
[3].
The perfect example of this appears in Schema Part 0 at [6]. I'd like to
bend that example slightly to
suit our discussion, so I've just attached the name to the complex type,
not some element:
<xsd:complexType name="internationalPrice">
<xsd:simpleContent>
<xsd:extension base="xsd:decimal">
<xsd:attribute name="currency" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
Let the prefix 'my' be associated with the target namespace of the schema
that defines the complex type above,
and consider the following type MIP assignment to a node called price:
<bind nodeset="price" type="my:internationalPrice"/>
I am saying that I believe this to be legal XForms that associates the
datatype xsd:decimal with the 'price' node.
By comparison, given the USAddress complex type from the Schema Part 0
purchase order example [7],
consider the following type MIP assignment:
<bind nodeset="someAddress" type="my:USAddress"/>
I believe this is not legal XForms because it does not assign a datatype.
Since no datatype is assigned,
I do not view this type MIP as having any bearing on the validity or
invalidity assessment performed by
an XForms 1.0 processor. So, if for example the 'zip' element were
missing from the content of someAddress,
I believe the XForms processor would not flag the someAddress node as
invalid during its checks of
type MIP conformance.
Moreover, I believe that an XForms processor does not even attempt to
validate a type MIP assignment
on an element that has any child elements because the default for the type
MIP is xsd:string.
[1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html
[2]
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#datatype
[3]
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#defn-validation-rules
[4]
http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#dc-defn
[5]
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#Type_Definition_Summary
[6] http://www.w3.org/TR/xmlschema-0/#complexTfromSimpleT
[7] http://www.w3.org/TR/xmlschema-0/#POSchema
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/09/2006 07:17 AM
To
<www-forms@w3.org>
cc
Subject
RE: XForms Basic and Schema Validation
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
> --------------------------------------------
>
>
Received on Tuesday, 9 May 2006 22:18:46 UTC