Subject: RE: [Simple] xcap issue 2: positional insertions

From: [email-masked]
Date: Mon, 10 May 2004 15:45:57 +0300

Yes, the xpath example I gave does not work. Jari suggests this:

/foo/*[1][name()="bar"] 

I don't know the difference between name() and local-name(). Anyway, this does not tell the server to insert <bar> before <baz>

I found that this works:

/foo/baz/preceding-sibling::bar[1]

Similarily

/foo/baz/following-sibling::bar[1]

can be used for inserting after.

Regards,
Hisham

> -----Original Message-----
> From: Jari Urpalainen [mailto:[email-masked]]
> Sent: 10.May.2004 15:09
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Simple] xcap issue 2: positional insertions
> 
> 
> On Mon, 2004-05-10 at 11:30, ext [email-masked] wrote:
> > This is good. I believe we need positional insertions.
> > 
> > My question is how does a positional insertion work for 
> elements with different names (the example you gave with 
> issue 1) where the uniqueness comes from the element name and 
> not an attribute?
> > 
> > eg:
> > <foo>
> >    <baz/>
> > </foo>
> > 
> > If I want to insert bar, and bar has to be inserted before 
> baz. Does it work like this:
> > 
> > PUT http://server/xcap-root/document/foo/bar[1]  
> > 
> > <bar/>
> > 
> > 
> > This works, I think, but the general rule you gave below 
> does not apply here (the unique-att thing).
> > 
> > /Hisham
> 
> Unfortunately, it does not work, you have to have a constraint like 
> 
> PUT http://server/xcap-root/document/foo/*[1]["bar 
> condition"] where any
> node "*" is used as Jonathan is proposing and  "bar 
> condition" could be
> e.g. an attribute constraint within <bar/> (not any in your 
> example). Of
> course this constraint could also be local-name()="bar" but 
> local-name()
> function is not yet allowed.
> 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> > > ext Jonathan Rosenberg
> > > Sent: 10.May.2004 08:27
> > > To: Simple WG
> > > Subject: [Simple] xcap issue 2: positional insertions
> > > 
> > > 
> > > A "positional insertion" is an operation on an XML document 
> > > that inserts 
> > > a new element as a child of a specified parent, and 
> > > furthermore, does so 
> > >   such that specific siblings appear before, and others 
> appear after, 
> > > the new element.
> > > 
> > > In other words, if I have the following document:
> > > 
> > > <foo>
> > >    <baz id="1"/>
> > >    <baz id="2"/>
> > >    <baz id="3"/>
> > > </foo>
> > > 
> > > Lets say I wish to insert a new element, <baz id="1.5"/> 
> that sits 
> > > between the <baz> elements with id 1 and 2. Such an insertion is 
> > > positional, since its asking for baz to be inserted in a specific 
> > > position relative to its siblings.
> > > 
> > > In the current xcap spec, such an insertion is not possible. 
> > > I went over 
> > > this during the Seoul meeting, and pointed out that this 
> > > feature would 
> > > not be necessary for most of the types of schemas we were 
> likely to 
> > > encounter. However, that proposition was true ASSUMING that 
> > > the server, 
> > > when it performed insertions, did so such that the resulting 
> > > documents 
> > > were still schema compliant, if possible. In another 
> email, regarding 
> > > open issue 1, I've proposed that the server become 
> ignorant of the 
> > > schemas when doing insertions. If that should happen, my 
> > > assumption no 
> > > longer holds, and we do really need positional insertions. 
> > > For example, 
> > > CPCP would really need them.
> > > 
> > > So, my proposal is to allow them. Jari has proposed a 
> simple way. We 
> > > extend the current xcap features to allow multiple 
> > > predicates, each of 
> > > which is ANDED together (this is a feature of XPath). 
> Each predicate 
> > > appears surrounding by square brackets (the []). We also need 
> > > to allow 
> > > the wildcard "*".
> > > 
> > > Now, lets once again consider how to insert the baz element 
> > > with id of 
> > > 1.5 between the ones with id 1 and 2. The following would 
> > > accomplish that:
> > > 
> > > PUT http://server/xcap-root/document/foo/baz[2][@id="1.5"]
> > > 
> > > <baz id="1.5"/>
> > > 
> > > Lets analyze this. The xcap URI resolves no no existing 
> > > element (none of 
> > > the baz elements have ID equal to 1.5). So, the content is 
> > > inserted. Its 
> > > inserted such that the URI now selects the new content. The 
> > > URI requires 
> > > this new baz element to be the second of of all baz's, and 
> > > further, that 
> > > its id be 1.5. The only way to accomplish that is by 
> > > inserting it into 
> > > the document such that it looks like this:
> > > 
> > > <foo>
> > >    <baz id="1"/>
> > >    <baz id="1.5"/>
> > >    <baz id="2"/>
> > >    <baz id="3"/>
> > > </foo>
> > > 
> > > which is the desired operation.
> > > 
> > > This approach is really general purpose, and will allow for easy 
> > > positional insertions so long as the new element differs in some 
> > > identifiable way from existing elements of the same name. 
> Currently, 
> > > that would be by attribute name and value.
> > > 
> > > Generally, to insert as the nth child under parent foo:
> > > 
> > > PUT 
> > > http://serverd/document/root/path-to-foo/foo/*[n][unique-att="
> > unique-value"]
> > 
> 
> There seems to be a typo as @ is missing before unique-att.
> 
> BR,
> Jari
> 
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 11 May 2004 07:58:42 +0300

> I don't know the difference between name() and local-name(). Anyway, this does not tell the server to insert <bar> before <baz>

Sorry, I did propose only local-name() (not any name()) function...
Anyway, the condition [1] tells exactly that the insert will have to be
the first node. This short form position index predicate (compare with
[position()=1]) tells the index, but of course it is not enough by
itself and you need some other constraints. Read the axis+predicates
like "any first node whose local-name()="bar"". Secondly, I am not very
convinced that we need local-name(). If we do, probably also
namespace-uri() is needed, but as I see it, the simpler the limited
XPATH logic in XCAP the better.

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 11 May 2004 07:58:42 +0300

BR,
Jari

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 May 2004 12:08:49 -0400

inline.

Jari Urpalainen wrote:

>> I don't know the difference between name() and local-name().
>> Anyway, this does not tell the server to insert <bar> before <baz>
>> 
> 
> Anyway, the condition [1] tells exactly that the insert will have to
> be the first node.

Right. The key thing to keep in mind is that two things need to be true 
in the URI if you want insertion:

1. it doesnt match any element in the document as it exists now,
2. it would match the new element only in the place where you want it to 
be inserted

OK, with this in mind, consider the general structure for these 
positional insertions:

foo/bar/*[position][uniqueness-constraint]

The * operator selects all children of bar. That list is subsetted by 
applying, in order (and it makes a difference!) the predicates expressed 
in brackets, from left to right. The first predicate says that "give me 
the first". That refers to the first child of bar (NOT the first child 
that matches the uniqueness constraint - thats why I say order matters). 
This constraint will, almost always, result in a match for something in 
the existing document. Its purpose therefore is to satisfy property (2) 
of the xcap URI - it will tell us something about the position where I 
want it to be inserted.

The second predicate, the uniqueness constraint, is needed to satisfy 
property (1) of the URI. It has to be something that doesnt match the 
position-th child of bar, but does match the new element. Currently, 
thats limited to unique attribute/values.

If we add the name() method (which is I think a good idea), we could 
also use the element name to differentiate. I *think* we want name() as 
opposed to local-name(); my read of the name() method is that it returns 
the fully qualified name. However I'm somewhat confused as to its 
handling of default namespaces. It seems that, if an element doesnt have 
an explicit namespace, but rather, is within the default namespace, the 
name() method returns only the local-name. Not sure if I'm doing 
something wrong in xml spy though...

  This short form position index predicate (compare
> with [position()=1]) tells the index, but of course it is not enough
> by itself and you need some other constraints. Read the
> axis+predicates like "any first node whose local-name()="bar"".
> Secondly, I am not very convinced that we need local-name(). If we
> do, probably also namespace-uri() is needed, but as I see it, the
> simpler the limited XPATH logic in XCAP the better.

Right.

> can be used for inserting after.

Yeah, this works, but I don't think its needed. You can achieve the same 
thing with the approach I describe, and I think its more general purpose.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 May 2004 12:08:49 -0400

inline.

Right.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 03:40:34 -0400

I believe we have reached conclusion on this thread and consensus. In 
particular, I believe we will allow positional insertions by allowing 
multiple predicates, allowing the "*" operator to select all children of 
a node, and allow the name() function.

Thanks,
Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 17 May 2004 03:40:34 -0400

Thanks,
Jonathan R.