W3C home > Mailing lists > Public > www-xml-query-comments@w3.org > January 2002

Data Model WD - Issue-0054: Complex types with simple content

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sun, 13 Jan 2002 14:20:54 +0000
Message-ID: <93539003455.20020113142054@jenitennison.com>
To: www-xml-query-comments@w3.org
Hi,

Re: Issue-0054: Complex types with simple content.

I strongly agree with this comment - complex types with simple content
should also have typed values. Otherwise it makes it very difficult to
get useful information from constructs such as the common <price
currency="GBP">12.99</price>.

I think that any element that has a non-absent [schema normalized
value] in the PSVI should have a typed-value; this includes elements
with complex types with simple content and elements with default/fixed
value constraints (which would be worth noting). It also means you
don't have to mention the special significance of xsi:nil, since it's
already covered in the definition of the [schema normalized value] in
the XML Schema Rec.

On the topic of the typed-value of an element, it's worth noting that
the [schema normalized value] PSVI property is described as a string
in the XML Schema Rec. Obviously you need to convert this string into
a sequence of typed values. I think that you could do this by stating
in Sections 4.2 and 4.3 that the [schema normalized value] is
converted into a sequence of simple types via the
simple-typed-value-from-string constructor in Section 5, although I
think that the signature of the constructor should be:

  simple-typed-value-from-string : (xs:string, SchemaComponent)
                                 -> Sequence<SimpleTypedValue>

if you're going to handle generating sequences of simple typed values
from strings like "1 2 3".

Note also that when getting the simple typed value for an element with
a complex type, the second input to the simple-typed-value-from-string
should be the element's [type definition]'s [content type] (which will
be a simple type definition in all applicable cases), rather than
simply the [type definition] (which you can use directly if the
element's type definition is a simple type definition).

I know that I commented before on getting access to the member type
definition (the title of Issue-0064 although the text of that issue is
actually about something completely different, about which more later
;). However, since the typed value of an element or attribute will
have that (member) type (rather than the union type), I don't think
it's a problem - just might be worth making a note that the type of an
element is not necessarily the same as the type of the simple typed
value(s) retrieved by the typed-value accessor.

Also on this topic, I notice that the string value of an attribute
node is normalized (according to the whitespace facet of its type); on
the other hand, the string value of an element node is not normalized.
I think that the string value of elements with simple content should
be normalized in the same way as the string value of attributes.

Cheers,

Jeni
---
Jeni Tennison
http://www.jenitennison.com/
Received on Sunday, 13 January 2002 09:22:33 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Monday, 13 June 2005 12:46:34 GMT