Subject: RE: [Simple] XCAP and its problem with Namespaces caused by using only the XML fragment body.

From: "Hyttfors, Per" <[email-masked]>
Date: Mon, 22 Aug 2005 14:16:11 +0200

Comments inline.

>
>This is clearly not optimal since it requires a full document 
>get just to obtain the namespace bindings. However, it works 
>with the current spec.
>

But at the same time the guidelines in 5.10 talk about the value of not
requiring a client to cache a copy of the document as well as the value
of having operations only taking a single request to perform.

So maybe not the best solution for XCAP to require clients to either
keep a cache up-to-date with the whole document or with all the
namespace bindings throughout the entire document.

>Some other thoughts are:
>
>1. an xcap extension that allowed to specifically query for 
>the namespace bindings in scope for a particular element
>

If this can be done within the original request (is that alternative 2?)
I think it has value. In case it would require a client to make two
requests it seems to make more trouble than it solves. I suppose that
the second request also would need to be conditional to safely assure
that the data and prefixes weren't changed since the initial element
fetch.

The client could request this additional information with a special HTTP
header tag or with the Accept-header. Is there something similar
available in other areas? If we cannot reuse an existing solution we're
somehow back at the first square.

This strategy could however also help guiding clients when adding a
fragment. They could query and use prefixes already available in the
context instead of adding new xmlns declarations with every fragment
added. It would unfortunately not force them to use it.

>2. change xcap so that what is returned is an xml fragment 
>that includes additional information on the namespace bindings in scope
>

W3C dealt with this problem years ago and came up with their XML
fragment entity. It is already a working standard and there has to be
several implementations already using this. Is there a specific reason
why the current specification requires only the fragment body and not
the fragment context specification? A look in that specification hints
that it was too verbose, giving information already available in the
URL, but you may have had other reasons too.

Another W3C standard that seems to deal with exactly the problems you
get when maintaining XML documents on a server is Exclusive XML
Canonicalization. To me this seems to be an ideal solution for us. The
fragment will simply inherit all the required namespace bindings and
include them as if it was part of the fragment. Technically this would
change the binary representation of the XML, but it helps keeping the
fragment semantically intact. The possible data overhead and the extra
processing power needed shouldn't be a problem.

>3. have the xcap server return xml data using the namespace 
>bindings in scope for the request URI. This requires the 
>server to modify the xml data before sending it to the client
>

Not sure if I understand this correct. Do you refer to the bindings done
already in the URI? Unfortunately they are only tracing the path to the
element and it does not include "superfluous" bindings that may be used
within the fragment received. It would not be sufficient to ignore or
remove the elements with bindings not understood as this will introduce
the risk of clients overwriting data in other namespaces on the server. 

Also, in my opinion we should not try to add more state to the URI
itself. 

If you weren't referring to the URL namespace bindings, maybe you were
approaching the XML Canonicalization idea.

>
>Yeah, this is another good point. This is the PUT eqiuvalent 
>of the GET problem you describe above. Here its easier though; 
>if the client doesn't know the namespace bindings because it 
>doesn't have the full document, it should include the bindings 
>in the fragment itself.
>

Easy solution but I can't help striving for perfection. Eventually the
document would be polluted with superfluous xlmns tags. An elegant
solution to this is could be, again, XML Canonicalization.

/Per

>-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
>

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