Re: Another DOM and XSL incompatibility?

James Clark wrote:

> Tyler Baker wrote:
>
> > In the DOM Attributes are not considered children of elements, yet in
> > XSL it seems that through the pattern matching capabilities the
> > Attribute nodes are considered to be SubNodes which I interpret as
> > "children" of element nodes.
>
> The spec needs a term to mean child node or attribute node.  It uses
> "subnode" for this; a subtree rooted at some element includes both the
> children and the attributes.  This doesn't mean that attributes are
> children.

This would be a good idea.  Someone who is just getting into stylesheets and
is not an expert on XML might get confused here.

> >  One thing I
> > have not found in the spec is whether this should be regarded as an
> > error
>
> The spec doesn't say it's an error, so it's not an error, though it
> would be reasonable to give a warning.
>
> Detecting all unmatchable patterns would be tricky.  Consider something
> like:
>
> foo[bar and not(bar)]

That is pretty obvious.  The thing I want to know is?  Should unmatchable
patterns (ones that can be resolved when building the stylesheet tree) flag
errors?  Should the XSL Processor be allowed to do this or else just pretend
everything is OK.

> > to whether you should select the element which has a "bar" attribute or
> > whether to select the "bar" attribute itself.
>
> The latter.
>
> >  Furthermore, if you do
> > indeed select the attribute (this is what my interpretation of the draft
> > says) then what if someone does something like:
> >
> > foo/@bar/@baz
> >
> > Should this be legal to or else just ignored...
>
> There's nothing in the spec that makes it illegal, so it's legal. There
> will never be any nodes that are selected by the pattern since attribute
> nodes can't have attributes.

Gotcha.  I and probably others thank you as usual for the quick reply to these
sort of questions.

Tyler


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