> > the [1] is optional but addresses the same path. > > > > i.e. /foo[1]/bar and /foo/bar address the same node no matter if the > > /foo has same name siblings or not. > > > > Hi Toby, > > As far as XPath per se is concerned, absolutely agree. However, the > index becomes significant when using XPath to search a repository e.g. > the queries "/jcr:root/foo/bar/element(*, my:type)" and > "/jcr:root/foo[1]/bar[1]/element(*, my:type)" aren't equivalent when > either foo or bar have same-name siblings. It would have been useful > if there was a method or switch available which would include all > indices in the path, but, as I say, it's easy to workaround so it's > not exactly a blocker. > > > > in any case, it's better to avoid SNS if the data model allows this, > > since they cause troubles in other places. > > regards, toby > > > > > Would you mind elaborating on what these problems are (before I start > to panic and rewrite our data model :-) ? - first of all, the paths are not stable. eg. if you remove a same name node all following node paths indexes change. - the Node.getName() cannot be used to address the node since it does not include the index.
there are certainly more i can't remember. but the first is the most severe problem. regards, toby -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
