I agree with amy ( partly)
The semantic argument is correct. The getPath() should either return the
path to the node, or a path to a set of similarly located nodes. The problem
is that both are valid and also both wrong. What we need is an
implementation that can delegate the path naming to some interface that is
appropriate for the context of the document that is being handled. This can
ensure that the proper Xpath return can be generated for the document
appropriate to the context and semantic f the application requesting the
response.
There is also a performance issue here. If the default getPath() has to
check the parent node sibling to check to number of nodes that have a
similar name, for every call then this is at best not optimal, and at worst
wrong
I would suggest that getPath() be modified to allow for a parameter to
determine the "pathing" mechanism, via an interface 'NodePathNamer'?
This would allow for some implementations of the interface to be
incorporated within the standard delivery, but also allow for Amy to
generate Xpath for her document to be in the form
'/document/properties/property[@name="whatever"]'
The default mechanism for the naming could be taken from the document (or
the document factory if there is no document present).
I would further suggest that there should be 2 interfaces to get the path,
one to get a path that (using some semantics) should yeald the node only, nd
one more generic
In summary
getPath() {
XpathNaming naming;
Document document =getDocument();
If (document == null) {
naming = getDocumentFactory().getGeneralXPathNaming ();
} else {
naming = document.getGeneralXPathNaming();
}
return getPath(naming);
}
and
getSpecificPath() {
XpathNaming naming;
Document document =getDocument();
If (document == null) {
naming = getDocumentFactory().getSpecificPath ();
} else {
naming = document. getSpecificPath ();
}
return getPath(naming);
}
and then we can delegate the actual naming mechanism
Mike Skells
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Amy Lewis
Sent: 06 June 2001 23:14
To: [EMAIL PROTECTED]
Subject: Re: [dom4j-dev] getPath()
Dear James and Emmanuel (and others),
On Tue, Jun 05, 2001 at 11:40:57AM -0700, James Strachan wrote:
>I think you're both right ;-)
>
>How about a compromise:
>
>* we add a warning to the JavaDoc that if you change the document in any
way
>then the XPath may no longer work.
>* I add a patch such that the index notation [2] is used if there are
>multiple siblings with the same QName.
>
>such that
>
>/root/nodeA/nodeB[2]/@attribute would occur if nodeA had 2 nodeB nodes but
>root had only one nodeA node.
>
>Sound like a good plan?
No.
*laugh*
Sorry. What I would prefer to do instead is ask:
what is the purpose of getPath?
Defining its purpose is likely to help define its semantics.
For instance: getPath() may be expected to return a valid XPath which
can be used to retrieve a nodeset, which this node is a member of. Or:
getPath() may be expected to return a valid XPath which can be used to
retrieve a nodeset, which is expected to have only a single member,
this node. Or: getPath() returns a list of ancestor nodes, in the form
of an XPath expression; the content of the nodeset returned by
evaluating the expression is not guaranteed, although it is likely to
contain this node.
My problem with the greater specificity is the means by which it is
obtained. Positional notation is a poor match for XML (in my opinion);
I don't see as much use of positional notation in XPaths as the XSLT
and XPath recommendations seem to suggest is likely. Let me provide an
example:
<document>
<properties>
<property name="whatever">value</property>
<property name="whenever">1:23</property>
<property name="however">fast</property>
<property name="never">now</property>
</properties>
</document>
This is not a terribly unusual document style, by the by. But the
choice of positional notation, rather than (in this case) value of an
attribute, makes the suggested default XPath generation less useful. I
don't *care* whether the document contains the "however" property in
position 3; I only care that the property I munge has the name
attribute "however".
Okay? I like getPath(), but I don't like the idea of even *trying* to
provide an XPath specific enough to generate a single-member node set,
because I don't think a generic algorithm can extract the interesting
information required for doing so (without expensive heuristics, that
is ... it *is* possible, in concept, and an interesting problem).
Using positional notation with XML doesn't strike me as a good thing.
Sorry.
Amy!
--
Amelia A. Lewis [EMAIL PROTECTED]
[EMAIL PROTECTED]
I don't know that I ever wanted greatness, on its own. It seems rather like
wanting to be an engineer, rather than wanting to design something--or
wanting to be a writer, rather than wanting to write. It should be a
by-product, not a thing in itself. Otherwise, it's just an ego trip.
-- Merlin, son of Corwin, Prince of Chaos (Roger Zelazny)
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
