On 08/ 3/10 01:52 AM, Darren Kenny wrote:
On 07/29/10 07:17 PM, Keith Mitchell wrote:
On 07/29/10 08:30 AM, Jack Schwartz wrote:
Hi Darren.
I agree that it is very useful to take a path. The proposal you laid
out looks good. I suggest an addition, based on a useful feature of
ManifestServ: the ability to add values to the search, to narrow it
down.
Suppose you have two elements of type X, one with value 1 and one with
value 2, and you want to retrieve the value of //X/Y but only for the
second X element. Something like //X=1/Y could specify this. (Pretty
sure that Xpath has a way to specify this kind of thing, though I
don't know it off hand.)
I believe the xpath syntax equivalent is:
/element[index]
e.g.,
/X[1]/Y[0]
Again, as in my response to Jack, I'm not sure that this is needed - name and
type should be sufficient for the majority of use-cases - since there is always
the ability to fall-back to using the DOC API specifically if a more complex
need is there.
I misunderstood Jack's suggestion, and I agree with your assessment. (In
any case, it could easily be added later as needed).
Darren:
I think the proposal is good - it's close enough to xpath to be
familiar, but different enough to be distinct. I do suggest putting the
"#num" and "?num" qualifiers in brackets, e.g.:
//obj[?3]/child[#3]/@someclass[0]/myobj.variable
Is there a specific reason for putting the ? and # operators in brackets? I just
ask since it's more readable to me to have:
//obj?3/ than //obj[?3]/
Mainly I'm not convinced that they add anything, but I'm open to convincing :)
While it was merely a suggestion and I'm content with either method, I
actually find the second form more legible. Also, on the chance that
complexity is added to the syntax later, I think the second form would
be cleaner for separating name/class from other parameters.
- Keith
Thanks,
Darren.
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
