[
Lists Home |
Date Index |
Thread Index
]
> I remember discussing the same kind of thing surrounding extension
> functions for XPath and why having a standard namespace for those
> extension functions is a good thing. I shouldn't phrase it so much in
> terms of moving a stylesheet from one environment to another -- what
> happens more often, and is more important for me as a programmer, is
> that *I* move from one environment to another, and *I* get confused
> remembering how a particular function (or axis) works in a particular
> environment :)
OK, I see what you mean. So i guess your prefixed axes gives more
visual guidance in this regard.
> But I think I'm probably misinterpreting what you meant with the
> schema:: axis -- I was thinking that it was getting all sorts of
> information from the schema, whereas I think you were mainly looking
> at accessing type information?
Yes, type information was my primary intention for the schema:: axis. But since
the type information is communicated as elements, they could have
substructures,
siblings and ancestors providing additional dynamic (type association) and
static
(schema structure) information.
> Of course one possibility would be that this Core XPath had a
> definition of a # or ~ abbreviation for a "property" axis, providing
> element nodes that represented whatever extra Infoset properties the
> upstream processor wanted to add to the particular node. So for
> example, if you did:
Yes, I think you're right, an property:: axis would be an even more suitable
name
for this thing since there is no point really in limiting it conceptually to
just schema
information.
Cheers,
David
|
