Re: namespace node implementation

On Wednesday, Oct 22, 2003, at 19:45 Europe/Berlin, Per Bothner wrote:

> james anderson wrote:
>>> Yes.  I think we're in violent agreement.  I was making the same 
>>> point to James Anderson.
>> no, i suggest that the distinction is slightly different.
> Sorry - I was over-simplifying.  We were disgreeing on the importance 
> of  "nice" namespace serialization (beyond correctness), but of course 
> you wouldn't emit obviousl;y redundant attributes.
>> to the best i could follow from the examples and the posted schematic 
>> algorithm, the proposal was to fabricate elevated namespace nodes as 
>> a side-effect of combination operations.
> I'm unclear on your terminology.  I don't know what an "elevated 
> namespace node" is or what you mean by "combination operations".

i was referring to this rule

> * When an element is constructed, its namespace mapping includes all 
> the "active namespaces nodes" (in the sense of the specification) plus 
> any of the namespaces in the prologue or predefined that are 
> referenced in the current element *or* (if this is a direct element 
> constructor) in any enclosed direct element constructors.  (This rule 
> is meant to minimize the number of distinct namespace mapping we have 
> to create. The implemengtatin may need to be a little bit clever > 
> here.)

which may not "fabricate", but does imply that namespace nodes are to 
be associated with an element in addition to those which were apparent 
either directly or in its ancestors. that's what i meant by elevation.

>   For the latter, do you mean element constructors with computed 
> content, such as:
> <a>{$b}</a>
> My proposal is to *not* fabricate any nodes as a side-effect, but to 
> *re-use* the namespace mapping of $b.

Received on Wednesday, 22 October 2003 14:49:44 UTC