Re: [Re: XPath to generate XML]

[Shekhar Jha <sh...@usa.net>]

The user will have to ensure the uniqueness of the path in that case i.e.
specify the path in the form of 

/Order/Customer[1]/Name

instead of 
/Order/Customer[1]/Name

Also as you pointed out that this application is kind of misuse of the XPath
which is for querying purpose, but if the things like about could be specified
as the part of contract requirement, it would reduce Line of Code in most of
the cases.
Shekhar Jha

Joseph Kesselman <ke...@us.ibm.com> wrote:
> Uhm. Just realized there's a problem with this concept. Maybe not a fatal 
> one, but enough to weaken its usefulness.
> 
> 
> The problem is that -- unlike directory names -- element names are not 
> guaranteed to be unique in a given context, and in fact often aren't. So 
> if you ask the tool to create the XPath /foo/bar/baz, that could be 
> satisfied correctly as long as foo has at least one child named bar which 
> has at least one child named baz. There may be lots of other content 
> before you reach that particular "bar", but it isn't relevant to this 
> XPath.
> 
> So you're only going to create _a_ matching document, and not necessarily 
> the one you had in mind... especially as the XPath becomes more complex 
> and/or you want to apply several of these create calls in succession to 
> build up the document you're interested in. (If I attempt to create that 
> same XPath again, do I reuse the existing bar and/or baz or create new 
> ones?)
> 
> 
> I think it's still an idea worth exploring a bit, simply because it's the 
> first attempt I've seen to use a path as a construction tool rather than a 
> query tool.... but I'm starting to think that XPath isn't the right 
> metaphor for this operation.
> 
> ______________________________________
> Joe Kesselman  / IBM Research