On Thu, Jun 07, 2001 at 11:25:37AM +0200, Emmanuel Dupouy wrote:
>Dear Amy,
>
>I think that we have to distinguish two fundamental uses of XML : document
>centric and data centric.
>
>An example of the first use can be illustrated here :
>
><Book title="A Title">
> <Chapter name="Chapter 1"/>
> <Chapter name="Chapter 2"/>
> <Chapter name="Chapter 3"/>
></Book>
>
>As you can imagine here the element position is fundamental. Moreover when
No.
The idea that the position of my arguments in a document, rather than
their content, is "fundamental" to them, is somewhat problematic. I
*can* locate paragraph three of section two of chapter six in the
second part ... but that I *can* doesn't make it either fundamental, or
best.
I could argue, indeed, that your positional notation wants to make the
XML static, rather than dynamic; read-only rather than read-write.
>you define an XML Schema the element declaration order is essential.
I am not at all sure of your point here. That the order of named
elements is significant goes without saying; what is the relevance to
the DOM4J API? If you're parsing a W3C XML Schema, and prefer to think
of /xsd:schema/xsd:complexType[3] ... position seems to me one of the
poorest of ways to identify a particular definition.
>In your example Amy, you use XML in a data centric way. And you don't mind
>the position of element.
I will happily admit that for certain applications, the only useful
distinction between neighboring elements of the same type is position
in the containing parent. I don't think it's a good *general* solution
for the problem of specifying a single node, and I don't believe there
is a good reason to require that getPath() return a single node, rather
than a set.
>So right now what getPath() method should return ?
>
>If we want to follow the W3C recommendation I believe that the use of
>element position is mandatory.
Red herring. There is no W3C recommendation on DOM4J. The XPath
recommendation does not specify anything about creating XPaths that
uniquely identify nodes (selectSingleNode, please note, is an
extension, albeit a commonly-used one). XPath on the whole deals with
node sets. Even XPaths with positional predicates are generally
defined as returning node sets, though with a clear (but unstated in
the recommendation specifically) use case for obtaining specific nodes.
/part/chapter/section/para[1] does not return a single node
(/part[2]/chapter[6]/section[3]/para[1] may, but it a) may not be the
node that you thought you wanted, and b) may not exist at all).
A great deal depends upon what the proposed use case for getPath() is,
which is why I mentioned three in the previous post. I don't see in
your response a discussion of what getPath() is *for*, except the
implicit assumption that it returns an XPath which, when evaluated,
returns a single-member node set containing the owner of getPath().
But I don't see why that particular interpretation should be preferred;
if I'm writing a document, perhaps I would *prefer* to see the
seventeen paragraph children of section two, chapter six, part two ...
but perhaps I have assigned IDs to sections, chapters, and parts, so
that I would prefer *not* to think of them as written by the mile and
cut off to fit, but identifiable parts of the argument that I am
making?
So before *everyone* has to deal with positional notation, I'd like to
see a justification for it, or I'd like to see a solution that allows
someone to enable/disable/override.
Or at minimum, I'd like to see a justification for why the method
getPath() ought to produce an XPath designed to produce a single
member, rather than an XPath that will return a larger node set.
Amy!
--
Amelia A. Lewis [EMAIL PROTECTED] [EMAIL PROTECTED]
I know you don't want either to give or to take. You've tried being the
giver, and you've found that the giver is always fooled. And you won't be
the taker, because that's very difficult, and because you know that the
taker always ends by hating the giver. You don't want ever again to have to
depend for happiness on another person.
-- Lord Peter Wimsey
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
