Subject: RE: [Simple] Re: A proposal for fixing the xcap schema problem andrelated issues

From: "Hyttfors, Per" <[email-masked]>
Date: Thu, 27 Oct 2005 19:03:16 +0200

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

Another attempt to explain my idea, using exclusive Canonicalization to
maintain each xml-fragment in a valid namespace scope:

When the server extracts an XML fragment from the document and separate
the selected node from its parent the server should include the omitted
namespace bindings so that the selected node's namespace context remain
valid. This is exactly what is achieved with exclusive XML
Canonicalization, but could also be accomplished with "normal" XML
Canonicalization, the only difference is that the exclusive version
excludes bindings that is not in use by the selected node and its
children.

The proposal is to demand that the server can respond with an XML
fragment body on the exclusive XML Canonicalization form that will
contain the elements and always a valid namespace context. 

This could be accomplished by changing the current form of the mime-type
"application/xcap-el+xml", or if compatibility with current
specification is of interest, as Jari has suggested before, by
introducing a new mime-type that a client can request instead.

One important thing to be aware of when receiving fragments that is in
exclusive XML Canonicalization form is that not only will all the
required namespace bindings be included, but the whole fragment will
follow the rules of Canonicalization.  
Hence the data in the fragment will be logically equivalent with the
corresponding part of the server document, however it will vary in
physical representation as the fetched fragment's representation will be
on the canonical form.

However I don't see that this could cause a problem, my understanding of
the XCAP specification is that there is nothing that requires that the
cached copy is bitwise identical to the server document.

Example:

The default ns for the AUID is "ns1". And the server document looks like
this:

<?xml version="1.0" encoding="UTF-8"?>
<foo:root xmlns:foo="ns1" xmlns:bar="ns2">
  <foo:element>
    <bar:element>
      <bar:child attr="value" b:attr="value" xmlns:b="ns3"/>
    </bar:element>
  </foo:element>
</foo:root>

This request:

GET ../~~/root/element/

will with this change return this:

<foo:element xmlns:bar="ns2" xmlns:foo="ns1">
  <bar:element >
    <bar:child xmlns:b="ns3" attr="value" b:attr="value"></bar:child>
  </bar:element>
</foo:element>

instead of this, as the current specification returns:

<foo:element>
  <bar:element>
    <bar:child attr="value" b:attr="value" xmlns:b="ns3"/>
  </bar:element>
</foo:element>

Clearly the Canonicalization allows the reader to understand what both
"foo" and "bar" is, in a way that the current specification doesn't.

As I see it, the only real problem is the GET case, the PUT case is not
a problem since you can always add the additional required namespace
bindings in your request to the server to make the fragment maintain a
valid namespace context. Some could argue that it will fragment the
server document with tons of superfluous namespace declarations taking
up unnecessary data space and that is of course correct.

Something that could minimize the superfluous namespace declarations
created by such PUT requests as well as making the cached document copy
bitwise the same as the server document is to always keep the server
document (as well as any client copy) in canonical form. The server only
needs to do XML Canonicalization after the addition of new data. The
strength of minimizing superfluous namespace declarations depends
heavily on where the bindings are in the document as well as if new
prefixes are introduced.

Conclusion:

The strength of this proposal:

1. No need for multiple requests to do one thing.
2. Requires very little change of the current specification.
3. The response could be a new mime-type leaving the current
"application/xcap-el+xml" as it is today.

The weakness of this proposal:

1. The server document can still be filled with superfluous namespace
declarations by clients that do not cache the server document.

Regards,

Per

Per Hyttfors 
_________________________________________________________
Development Engineer - Messaging Application Development 
Sony Ericsson Mobile Communications AB 
SE-221 88 Lund, Sweden 
+46 46 2126534 
[email-masked] (MSN/E-mail) 
_________________________________________________________

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