Lists Home |
Date Index |
> >> 2. It's a heck of a lot easier to create a new XPath function in
> >> existing public domain XPath implementations than it is to change
> >> the parsing and execution model.
> > This is very true, and another key reason with my uneasiness with
> > extension axes.
> But this is why I'd like to see XPath-NG defined differently. Rather
> than listing all the possible axes, you'd have:
> AxisName ::= QName
> and then it would be up to separate modules to specify useful axes for
> that module.
Yeah. As I give it more thought, I think that extension axes need not be as
big a deal as I first thought. It would certainly involve a refactoring of
4XPath, and would move axes from the grammar to the symbol table code, but
it's feasible, and besides the inevitable loss of performance does not really
harm the architecture.
> > Looks good, and pretty much what I've proposed, but I still wonder what the
> > form is of annotation nodes. Are they the data model equivalent of
> > <annotation id="type">integer</annotation>
> > for example?
> I'd prefer them to be elements identified by name. For example:
Fine with me. I guess that means that there have to be namespace nodes added
for the annotation nodes somehow.
> >> Of course, I still haven't figured out how to set the context up
> >> yet for annotations, but still I have a few weeks to do some more
> >> design.
> > I think that once we figure ou the data mnodel for annotations, we
> > can come up with a context analog. For example, if we go with my
> > annotation element above, then we might say, roughly that such
> > elements are top-level elements in a separate, special annotations
> > document which contains all the annotation nodes for a given XML
> > source document. The annotations() function could then be defined as
> > shifting the context *as if* it were an axis which selected a set of
> > annotation nodes as the new context node list.
> Hmm... Do you think that it's too loose to leave it up to the
> particular annotation to determine what other structure might be
> defined around the element node that's returned through this function?
> It would be useful if you could use an annotation that gives you a
> hook into the PSVI as a starting off point for navigating the PSVI,
> for example. Or an annotation might be standalone, in its own document
> for all intents and purposes. What matters is that the annotation
> function/axis returns a bunch of element nodes -- I don't think that
> we really need to care where they come from.
I think we do for a few reasons. What is considered the base URI of those
annotation nodes? What happens if one navigates the parent or ancestor axis
on one of them, or uses an absolute path with an annotation node as context?
For all these issues to have clear definition, which I think is important, we
need to have a model for the provenance of annotation nodes. IMO, if you put
together enough of a clear definition of all the issues in question, you would
have already done enough to *imply* a model for annotation node provenance.
> > Then again, as I think of it, this may also introduce implementation
> > difficulties. In 4Suite, this would work because extension functions
> > receive a mutable instance of the context. I expect this is not the
> > general case. Do other processors pass the context to extension
> > functions by value rather than reference?
> I don't understand why this is required. Can you explain a bit more?
Never mind. The question originated in muddy thinking.
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork