Subject: [Simple] xcap multiple insertions

From: Jari Urpalainen <[email-masked]>
Date: Thu, 04 Mar 2004 10:56:41 +0200

Hi Jonathan !

I read your XCAP representation in Seoul and I'll have a few comments.

When selection multiple entries you can't use union "|" there. Union is
used to select multiple location paths like

/element[@attr="test"] | /element/test

The working solution is to use position() function and "or" logical
expression i.e.

/element[position()=1 or position()=2]

Secondly, you may have missed my earlier posting, where I proposed that
index could be added onto XPATH expression when one wants to insert new
item at a specific location i.e.

/element[@attr="test"][2]

which says that you want to insert new item as second item and whose
attr="test" (assuming of course that you have already many elements and
the selection uniquely identifies the new item). As the selection
results as zeros nodes (does not exist yet) then you know that you want
to add this item and you effectively have to insert this new item
between the original first and second item. And certainly you can get
the same data with the same query afterwards.

I'll admit that I am not aware of use-cases for this but IMO the logic
is so simple that it could be allowed.

Furthermore, when you give examples I would prefer that you give
absolute location paths instead of relative as that is the semantics in
XCAP currently.

Btw. has anybody complained about the case how to detect file-part and
XPATH-query from each other ? I could propose that an additional slash
would be added there i.e. http://example.com/file.xml//list. This would
help if XPATH-set in XCAP would be extended e.g. with anywhere test
"//".

BR,
Jari

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Mar 2004 01:53:36 -0500

Thanks for the comments. inline.

> used to select multiple location paths like

Yes, I noticed that xml spy didnt seem to like these expressions, but 
according to the spec at least they seemed ok. From the xpath spec:

[8]   	Predicate	   ::=   	'[' PredicateExpr ']'	
[9]   	PredicateExpr	   ::=   	Expr	
[14]   	Expr	   ::=   	OrExpr	
[21]   	OrExpr	   ::=   	AndExpr	
			| OrExpr 'or' AndExpr	
[22]   	AndExpr	   ::=   	EqualityExpr	
			| AndExpr 'and' EqualityExpr	
[23]   	EqualityExpr	   ::=   	RelationalExpr	
			| EqualityExpr '=' RelationalExpr	
			| EqualityExpr '!=' RelationalExpr	
[24]   	RelationalExpr	   ::=   	AdditiveExpr	
			| RelationalExpr '<' AdditiveExpr	
			| RelationalExpr '>' AdditiveExpr	
			| RelationalExpr '<=' AdditiveExpr	
			| RelationalExpr '>=' AdditiveExpr	
[25]   	AdditiveExpr	   ::=   	MultiplicativeExpr	
			| AdditiveExpr '+' MultiplicativeExpr	
			| AdditiveExpr '-' MultiplicativeExpr	
[26]   	MultiplicativeExpr	   ::=   	UnaryExpr	
			| MultiplicativeExpr MultiplyOperator UnaryExpr	
			| MultiplicativeExpr 'div' UnaryExpr	
			| MultiplicativeExpr 'mod' UnaryExpr	
[27]   	UnaryExpr	   ::=   	UnionExpr	
			| '-' UnaryExpr	
[18]   	UnionExpr	   ::=   	PathExpr	
			| UnionExpr '|' PathExpr	
[19]   	PathExpr	   ::=   	LocationPath	
			| FilterExpr	
			| FilterExpr '/' RelativeLocationPath	
			| FilterExpr '//' RelativeLocationPath	
[20]   	FilterExpr	   ::=   	PrimaryExpr	
			| FilterExpr Predicate	
[15]   	PrimaryExpr	   ::=   	VariableReference	
			| '(' Expr ')'	
			| Literal	
			| Number	
			| FunctionCall	

following this chain of grammar, I concluded that I could have a 
predicate that was an OrExpr, which is an AndExpr, which is an 
EqualityExpr, which is a RelationalExpr, which is an AdditiveExpr, which 
is a MultiplicativeExpr, which is a UnaryExpr, which is a UnionExpr, 
which can be a series of PathExpr separated  by '|', and PathExpr can be 
a FilterExpr which can be a PrimaryExpr, which can be a Number. Thus, 
the predicate 1|2|3 seemed allowed.

What am I missing??

> /element[@attr="test"][2]

It wasnt clear to me how this is allowed; the basic grammar for step is:

[4]   	Step	   ::=   	AxisSpecifier NodeTest Predicate*	
[8]   	Predicate	   ::=   	'[' PredicateExpr ']'	

which would seem to rule out the above.
Perhaps you could do it with:

/element[@attr="test" and position()=2]

I'll also note that I found xpath confusing with regards to the 
definition of the position() function. It says:

The position function returns a number equal to the context position 
from the expression evaluation context.

However, I could find no formal definition of the context position. Its 
not in InfoSet either.

> the same data with the same query afterwards.

This sounds right. You'd need to have the constraint that the attribute 
is different compared to the element at the specific location, assuming 
the element has the same name as the one to be inserted. Not a bit 
constraint.

> is so simple that it could be allowed.

What came up during the tutorial session was, if you wanted for the xcap 
server to NOT need to understand the schemas for extensions, you would 
need the client to make sure that the changed document was 
schema-complaint. This would definitely require specifying exactly where 
to insert an element. So, with this, we could in principal keep with the 
idea that the server doesnt need to know the schema, though I'm not sure 
we want to...

> absolute location paths instead of relative as that is the semantics in

OK, thanks.

> XPATH-query from each other ? 

No. I did point this out as a limitation with the "/" separator approach 
however.

I could propose that an additional slash
> help if XPATH-set in XCAP would be extended e.g. with anywhere test

Hmm. Thats interesting. It does appear to be a valid http URI according 
to rfc2396; I wonder if intermediaries would possibly have heartburn 
over it though? That was the big issue with using the query parameter "?".

-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: Thu, 11 Mar 2004 01:53:36 -0500

What am I missing??

OK, thanks.

-Jonathan R.

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 11 Mar 2004 12:17:18 +0200

> the predicate 1|2|3 seemed allowed.
As can be seen ;) these specs are so nice, simple and easy to
interpret... I must confess that I haven't payed much attention to this
grammar. However, the problem isn't actually just syntactic (so the
syntax you propose is IMO right) but more semantic. When conditions are
added to test location paths, the result of condition should be of type
boolean and of course to pass the test it should be true, so in this
particular case, what is the result of union of 1, 2 and 3 ? IMO it is
just ~true (and this seems to be also the interpretation of the
xml-library that I usually utilize (libxml2). 

Furthermore, I could point e.g. to these two references which have IMO
good examples, how XPATH selections work (or should work?)

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/htm/xpath_syntax2_3prn.asp

http://www.w3schools.com/xpath/xpath_syntax.asp

In the latter you'll see union examples in "Selecting Several Paths"

> /element[@attr="test" and position()=2]
IMO this is the equivalent format that can also be used. I have always
read the grammar so that you can have many predicates which are
effectively anded together (look msdn ref and also works with libxml2)

> over it though? That was the big issue with using the query parameter "?".
equally valid uri would be http://example.com/file.xml/./list. While the
current approach can be implemented e.g. by searching the last possible
au root node or searching through path step by step the "real" file (+
magic when new file should be created with put), I'll find the logic
explicitly ugly and the former query (or fragment) parameter was a lot
better in this respect. So I don't see this a must to be fixed, but
preferably it will be.

Thanks,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 11 Mar 2004 12:17:18 +0200

Thanks,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 26 Mar 2004 09:15:07 +0200

> effectively anded together (look msdn ref and also works with libxml2)
I decided to go ahead to try multiple inserts/replaces/deletes in
practice and I found that all but delete behavior is IMO consistent and
easy to implement (also ordered inserts work). What bothers me in
delete, is that it is not easy to see from the XPATH expression how many
elements is going to be deleted. Of course, in get and in put you'll
don't have this problem as e.g. in partial put you'll provide equal
amount of sibling members that the query must match. Therefore, I'll
propose that union would be used with full location paths and each
expression would have to point to a single node(set), the constraint of
which is already inherent in XCAP. 

This would result in somewhat lengthier XPATH-compatible expressions but
it would also enable to select other nodes from the doc than only
siblings (there might be need for that also in CPCP as I heard). 

Also, this would be a small add-on to XCAP BNF, where btw. I would like
to see also text-node predicates like [item="foo"] and also the current
"." selection like [.="bar"].

BR,
Jari

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 26 Mar 2004 09:15:07 +0200

BR,
Jari