OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XPath/XSLT 2.0 concerns

[ 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
siblings and ancestors providing additional dynamic (type association) and
(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
for this thing since there is no point really in limiting it conceptually to
just schema



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS