[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Content constructors and sequences


Subject: Re: [xsl] Content constructors and sequences
From: naha@xxxxxxxxxx
Date: Wed, 09 Jan 2002 16:17:02 -0500 (EST)

Quoting Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>:

[...]

> Putting it another way, sequence constructors can either construct
> sequences holding a number of documentless nodes, or a sequence
> containing any kind of items. It's a dynamic error if the result
> sequence contains documentless nodes and either simple typed values or
> pre-existing nodes.

Why is it that the sequence itself can't be considered to be a
document?

<rant ranter-bias="lisp programmer">
I was first attracted to XML and its associated technologies because
it profided a simple means of encoding arbitrary data in a textual
form, though perhaps a somwhat cumbersome one.  Then, for some reason,
the XML Schema data model came along and added needless clutter to
what was a simple model.

XMLSchema allows for data to be represented in a structured textual
way that is different from XML (or at least that which it was previously).
XML was sufficient.  The other representations (e.g. space delimited
sequences in attributes) are just syntactic sugar.

Rather than requiring additional data types, Schema should just have
provided a way to describe how such syntax should be mapped into the
existing data model.

One would need to enrich the data model a bit by removing some
restrictions concerning attribute values.  But I think of attributes
as an anachronistic throwback anyway.  The representation is
sufficiently powerful without them.

Many beginners to XML modeling ask whether one should use an attribute
or an element for a given datum to be modeled.  There's no good answer
because there's no meaningful distinction.

I like to think of XML as being S-expressions with really fat
parentheses.
</rant>


[...]

> Hmm, good point.
> 
> I see three possibilities:
> 
> First, you could just not worry about it. An attribute's name is a
> xs:QName, which incorporates the namespace URI so there's no problem
> getting that namespace URI. If an attribute's typed value is a
> xs:QName or a list of xs:QNames (which it should be if the values have
> are qualified names), then each of those xs:QName values must have its
> own namespace URI accessible as well. So an attribute doesn't need
> namespace nodes. (Possibly - can you think of some examples where you
> need to access a namespace node given you have access to a QName?)

This is admittedly a stretch, but the value of the attribute could be
a string containing QNames, for example, an XPath expression.  Then again,
one could probably construct such a degenerate case in 1.0 as well.

> Second, you could make the presence of documentless attribute nodes in
> sequences assigned to variables a dynamic error (and you might want to
> do the same for documentless namespace nodes). That would force people
> to use element node 'holders' for them instead.
> 
> Third, you could change the data model so that the namespaces
> accessor on attribute nodes returned a sequence of in-scope namespaces
> for that attribute. That would be a departure from the XML Infoset,
> though.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread