Re: XQuery/XPath Data model comments

Hi Marton,

Thanks for the reply to my comments.

> I don't think this works.  The only way you can tell whether a text node
> comprised only of white space characters is with a schema, DTD, or some
> other annotation (<xsl:strip-space/>).

Ah, OK. I'd misunderstood the way in which the ignore-whitespace flag
was supposed to work. I thought that it was saying that these were the
*only* nodes categorised as insignificant whitespace, and that other
nodes were just seen as text nodes. I thought that xsl:strip-space
would be defined as in terms of setting the ignore-whitespace flag to
boolean true for the content of the elements that it named, not that
xsl:strip-space would be able to reclassify nodes as insignificant
whitespace. Perhaps there could be a clarification here just to say
something like that applications could provide their own information
for identifying insignificant whitespace on top of that provided by
the schema.

>> Why don't namespace nodes have parents? It's useful to be able to
>> continue to traverse a tree from namespace nodes. For example, in
>> stylesheets for browsing XML documents, you can only work out
>> whether a namespace needs to be declared by looking at the
>> namespace nodes on its ancestors (e.g.
>> ancestor::*/namespace::*[name() = name(current()) and . =
>> current()]).
>
> In order to have parents, namespace nodes must have unique identity.
> This results in either a huge explosion in the number of nodes that
> must be stored in the data model, or requires contextual information
> to be passed around to simulate unique nodes virtually.
> Nevertheless, your expression will continue to work in XPath 2.0; it
> doesn't depend either on the identity of namespace nodes nor on
> their parentage. The namespace axis, followed from an element, will
> continue to give all the namespaces that are in-scope for that
> element, and this, we believe, accounts for 99% of actual usage.

Yes, that was a bad example. Actually, in a stylesheet I've been
working on recently, I have a whole bunch of paths of the form:

  namespace::*[name() = substring-before(../@type, ':')]

in order to deal with QNames. But then I imagine that there'll be
better support for QNames in the future in any case, and this won't be
necessary.

> The current plan is to return SchemaComponents representing anyType
> or anySimpleType. In other words, there is no schema-less document,
> only documents with a default, highly generic, schema applied.

Sounds good.

> The presence of xsi:nil="true" means that the element is empty;
> nothing special needs to be done with the type (but the element
> needs to be nillable).
> The typed-value() function works as follows on an empty element:
> If the type of the element is string or derived from string, 
> and the element does not have xsi:nil="true", 
> then typed-value() returns the zero-length string.
> Otherwise typed-value() returns the empty sequence.

Right, so you can tell if a element is nil because its typed-value()
is an empty sequence. Makes sense.

> Reference nodes have been removed from the data model.

Good :)

>> 5.2 Derived Simple Values. The way that this section uses the term
>> 'primitive' is confusing. Is the intention that the only value
>> types that are supported within the data model are the primitive
>> types from XML Schema?
>
> All values (but not all types) must be one of the primitive types
> from XML Schema.

OK... You should change paragraph 2 of section 4.2 which talks about
constructors for primitive types and then gives an example using
xs:integer, which isn't a primitive type.

>> If so, what's the purpose of separate constructors for all the
>> built-in data types, as given in the F&O WD, as xf:short() will
>> give exactly the same type of value as xf:decimal()?
>
> The value xf:short(1) and xf:decimal(1) are the same. The types are
> different.

Ah... light is kind of dawning :)

>> If that's not the intention, could you use something else instead
>> of the term 'primitive value' within this section?
>
> I think we correctly use the terms primitive values and primitive
> types, and although the difference is subtle, I don't quite know how
> to improve the text. I'd welcome suggestions.

No, I think it's fine. It was the inclusion of xs:integer and xs:IDREF
as examples of primitive types in the previous section that threw me,
because they're not primitive types according to XML Schema, so I
thought you were changing the meaning of the term.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Friday, 2 November 2001 04:41:59 UTC