Subject: [Simple] Re: A proposal for fixing the xcap schema problem and related issues

From: "Ramalakshmi V. Gunturi" <[email-masked]>
Date: Thu, 13 Oct 2005 12:28:30 +0530

With reference to the earlier mail http://www1.ietf.org/mail-archive/web/simple/current/msg05810.html,

>>>>>>>>>>>>>> Quoting from the earlier mail >>>>>>>>>>>>>.

I would update the grammar of the node selector to allow for 
namespace::*. Such a selector would select the namespace bindings in 
scope for the element in question. xcap would define a format for 
encoding those namespace bindings; basically, an xml fragment body with 
one element, the local name of the element in question, with xmlns and 
xmlns: attributes for each of the namespaces in scope, including the 
default.

For example, consider this document:

    <?xml version="1.0" encoding="UTF-8"?>
    <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <service uri="sip:marketing at example.com">
       <a:list name="marketing">
         <a:entry uri="sip:joe at example.com"/>
         <a:entry uri="sip:sudhir at example.com"/>
       </a:list>
       <packages>
         <package>presence</package>
       </packages>
     </service>
    </rls-services>

The following query:

GET 
http://xcap-root.com/rls-services/users/joe/~~/rls-services/service/namespaces::*

would return:

    <service xmlns="urn:ietf:params:xml:ns:rls-services"
       xmlns:a="urn:ietf:params:xml:ns:resource-lists"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>

This fixes the problem by allowing the client to get the in-scope 
bindings, and cache them, so they can be used to interpret subsequent 
GETs, and then used to create the namespace prefixes for elements in 
subsequent PUTs. Of course, the client needs to be sure that the cached 
namespace bindings havent changed prior to the PUT; the mechanisms in 
section 7.10 of XCAP apply here as normal.

<<<<<<<<<<<<<< end quoting from earlier mail <<<<<<<<<<<<<<<<<

As per my understanding, the above approach needs the whole request formation part to be done at runtime. Please correct me If I am wrong. 

My question is that, If we want to identify and define the parameters that make up each request in a xml document, and then define another XSLT document to transform the request from the fomer XML document to an XCAP format, we will need to use standard parsers and transformers.

In this scenario, for put requests with xml fragments having namespaces,  the parser throws an error because in the payload there is no definition of namespace.
ex:
	fergus wants to add foo to his accept list.

				PUT http://xcap.example.com/services/org.openmobilealliance.poc-rules/users/sip:[email-masked]/pocrules/~~/cr:ruleset/cr: rule[@id="accept"]/cr:conditions/cp:identity/cp:entry?xmlns(cr="urn:ietf:params:xml:ns:commonpolicy")xmlns(cp="urn:oma:params:xml:ns:commonpolicy") HTTP/1.1
 
		<cp:entry id="sip:[email-masked]" />

So when this payload in defined in the XSLT document and the XSL Transformer (javax.xml.transform.TransformerFactory) is used for generating the XCAP request, the transformer throws out an error saying "cp:entry not bound to parent", because as per the xml rules, the name space is not defined within the payload.

How do we overcome these type of issues ??

Thanks & Regards,
Rama

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 21 Oct 2005 03:20:58 -0400

inline.

Ramalakshmi V. Gunturi wrote:

> With reference to the earlier mail
> http://www1.ietf.org/mail-archive/web/simple/current/msg05810.html,
> 
> 
>>>>>>>>>>>>>>> Quoting from the earlier mail
>>>>>>>>>>>>>>> >>>>>>>>>>>>>.
> 
> 
> encoding those namespace bindings; basically, an xml fragment body
> with one element, the local name of the element in question, with
> xmlns and xmlns: attributes for each of the namespaces in scope,
> including the default.
> 
> <?xml version="1.0" encoding="UTF-8"?> <rls-services
> xmlns="urn:ietf:params:xml:ns:rls-services" 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <service
> uri="sip:marketing at example.com"> <a:list name="marketing"> 
> <a:entry uri="sip:joe at example.com"/> <a:entry uri="sip:sudhir at
> example.com"/> </a:list> <packages> <package>presence</package> 
> </packages> </service> </rls-services>
> 
> The following query:
> 
> GET 
>  subsequent PUTs. Of course, the client needs to be sure that the
> cached namespace bindings havent changed prior to the PUT; the
> mechanisms in section 7.10 of XCAP apply here as normal.
> 
> As per my understanding, the above approach needs the whole request
> formation part to be done at runtime. Please correct me If I am
> wrong.

Yes, you are right. I will note that allowing xcap operations to happen 
using a statically configured query (i.e., not computed at run time) has 
not been a requirement. I understand why you want to do it, but its not 
been a requirement to date.

The only two ways I know of, which would allow you to have a static 
query that will work are:

1. require standardized definitions for namespace prefixes
2. namespace bindings can already been includedin the request-URI. These 
are used only to define the in-scope bindings for evaluating the URI. 
Also apply them to the fragment in a PUT, and then have the server 
modify the namespace prefixes in the fragment to equal those defined for 
the same namespace URI.

#2 is really ugly, and violates the http spec itself (get(put(x))) won't 
equal X. #1 interacts poorly with non-standard extensions and violates 
the spirit of xml namespace, i think.

I welcome other proposals, but the one I propsoed was the best I could 
think of.

> 
> My question is that, If we want to identify and define the parameters
> that make up each request in a xml document, and then define another
> XSLT document to transform the request from the fomer XML document to
> an XCAP format, we will need to use standard parsers and
> transformers.
> 
> In this scenario, for put requests with xml fragments having
> namespaces,  the parser throws an error because in the payload there
> is no definition of namespace. ex: fergus wants to add foo to his
> accept list.
> 
> PUT
> http://xcap.example.com/services/org.openmobilealliance.poc-rules/users/sip:[email-masked]/pocrules/~~/cr:ruleset/cr:
> rule[@id="accept"]/cr:conditions/cp:identity/cp:entry?xmlns(cr="urn:ietf:params:xml:ns:commonpolicy")xmlns(cp="urn:oma:params:xml:ns:commonpolicy")
> HTTP/1.1
> 
> So when this payload in defined in the XSLT document and the XSL
> Transformer (javax.xml.transform.TransformerFactory) is used for
> generating the XCAP request, the transformer throws out an error
> saying "cp:entry not bound to parent", because as per the xml rules,
> the name space is not defined within the payload.

I don't quite follow this, so I can't tell if this is a problem with 
using this particular java library to generate the xcap query, or 
whether there is a protocol issue here. Can you clarify?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Sebastian Ley <[email-masked]>
Date: Tue, 25 Oct 2005 13:41:38 +0200

> the spirit of xml namespace, i think.

Correct me if I am wrong, but I thought that the get(put(x)) == x requirement 
is from XCAP. HTTP mandates idempotency which is satisfied even with the 
prefix mangling suggestion above. Right? 

In that case we would "just" need to drop the above requirement and revert to 
the HTTP idempotency to make solution 2 possible. That means extra work for 
the server, but takes a lot complexity from the clients, allows for single 
pass updates and static URI construction.

Together with a former suggestion of Per Hyttfors who proposed to solve the 
namespace querying for GETs with XML Canonicalisation 
(http://www.ietf.org/mail-archive/web/simple/current/msg05728.html) that 
would make client implementations very simple and put all namespace resolving 
"burden" on the server. That sounds like a good idea to me.

Regards,
Sebastian

-- 
Blog: http://www.withouthat.org/~sebastian/blog
PGP-Key: http://www.withouthat.org/~sebastian/public.key
Fingerprint: A46A 753F AEDC 2C01 BE6E  F6DB 97E0 3309 9FD6 E3E6

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Oct 2005 00:03:51 -0400

inline.

> prefix mangling suggestion above. Right? 

Hmm. Fair point. You are right. We long ago decided that with xcap we 
would meet the idempotency requirement by maintaining the property that 
get(put(x))=x.

However, there are other issues with the namespcae prefix munging, which 
Martin just posted on.

> pass updates and static URI construction.

Well, the hashing approach also removes complexity from clients, allows 
for single pass updates and static URI construction too. Its also less 
verbose than a rewrite, since it would reqiure you to declare the 
namespace prefixes you used in the fragment. And it doesnt have the 
other issues with namespace munging that Martin referenced.

> "burden" on the server. That sounds like a good idea to me.

I'll be responding to that note in a moment. Unfortunately I don't 
follow the proposal; I'm not an expert in the canonicalization spec. Can 
you or Per summarize the idea?

Thanks,
Jonathan R.

---

From: Sebastian Ley <[email-masked]>
Date: Wed, 26 Oct 2005 14:16:55 +0200

* Jonathan Rosenberg wrote:

> > Correct me if I am wrong, but I thought that the get(put(x)) == x
> > requirement is from XCAP. HTTP mandates idempotency which is satisfied
> > even with the prefix mangling suggestion above. Right?
>

Hm, I can't find that one... Which post do you mean?

> > In that case we would "just" need to drop the above requirement and
> > revert to the HTTP idempotency to make solution 2 possible. That means
> > extra work for the server, but takes a lot complexity from the clients,
> > allows for single pass updates and static URI construction.
>

While it is true, that the hashing approach solves the namespace mess
for both, PUTs and GETs, it has a major impact on human readability,
which was (IMO) always a great asset of XML. An example from the spec:

   <foo xmlns="urn:test:default-namespace">
     <ns1:bar xmlns:ns1="urn:test:namespace1-uri"
              xmlns="urn:test:namespace1-uri">
       <baz/>
       <ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
     </ns1:bar>
   </foo>

becomes (after md5sum | base64-encode):

   <foo xmlns="urn:test:default-namespace">
     <MWE2NDI0MDRlNTc1YTM1Y2FmNGE0NzdkNWI0OTEzYWUgIC0K:bar
              xmlns:MWE2NDI0MDRlNTc1YTM1Y2FmNGE0NzdkNWI0OTEzYWUgIC0K="urn:test:namespace1-uri"
              xmlns="urn:test:namespace1-uri">
       <baz/>
       <Y2MyYjQ3NTQ0NjBkZDEyMjE3YmEwYmFkYzdlZjBjMzUgIC0K:baz
              xmlns:Y2MyYjQ3NTQ0NjBkZDEyMjE3YmEwYmFkYzdlZjBjMzUgIC0K="urn:test:namespace2-uri"/>
     </MWE2NDI0MDRlNTc1YTM1Y2FmNGE0NzdkNWI0OTEzYWUgIC0K:bar>
   </foo>

While my computer has no problem in eating this, I certainly have my
problems ;-)

> > Together with a former suggestion of Per Hyttfors who proposed to solve
> > the namespace querying for GETs with XML Canonicalisation
> > would make client implementations very simple and put all namespace
> > resolving "burden" on the server. That sounds like a good idea to me.
>

I reckon you found Per's summary of the idea from his previous post.
You are right, it only fixes the GET case. It is obsolete if you want to
apply the hashing solution,  but for the above reasons, I would advise
to reconsider that...

Regards,
Sebastian