[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] XCAP and its problem with Namespaces caused by using only the XML fragment body.
Hello,
As I see it there is a major problem with
retrieving elements in an XML document using XCAP. The problem has to do with
that the XDM clients has to know all the namespace prefix bindings in the server
document prio the fetch of an element.
The problem is that the current XCAP
specification only mandates that a XCAP fragment body is sent between server and
client when performing XCAP operations. Not being an fcs document with the
fragment context specification leads to problems now when the XCAP URL has been
made independent of the namespaces prefixes used in the document on the
server.
The XML data returned in the 200 OK answer
on a fetch of an element will contain the exact content of that element in the
XML document on the server. If this element or any child elements use namespace
prefixes declared earlier in the document they will not be included in the
response to the client. Hence the only way to know all the prefixes is to have
done a fetch of the whole document.
Just to clarify
the problem I have made these examples (inspiration from the XCAP
specification..)
Bill has not
fetched the whole server document, and it looks like this:
<?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>
Bill
decides to get the service information for uri
sip:marketing at example.com
and the server
responds:
HTTP/1.1 200
OK
Etag: "ad88"
Content-Type:application/xcap-el+xml
<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>
Bill is now confused as he has no idea what
namespace the tags that are using the namespace prefix a: belongs to, so he has
to fetch the whole document to find out....
This
would be a situation where the client would have a problem if the xmlns
declaration is missing in the XML fragment body:
The server document looks like
this:
<?xml version="1.0"
encoding="UTF-8"?>
<a:resource-lists
xmlns:a="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<a:list name="close-friends">
<a:display-name>Close
Friends</a:display-name>
<a:entry
uri="sip:joe at example.com">
<a:display-name>Joe
Smith</a:display-name>
</a:entry>
</a:list>
</a:resource-lists>
Bill creates an element in the
resource-lists document (Section 7.4). In particular, he creates a list
with an entry:
<list name="friends">
<entry uri="sip:bob at example.com">
<display-name>Bob Jones</display-name>
</entry>
</list>
Bill will cry as the validation of the document after the tentatively
insertion will fail as this will produce a invalid XML document..
/Per
Per
Hyttfors
___________________________________________________________
Development
Engineer - Messaging Application Development
Sony Ericsson Mobile
Communications AB
SE-221 88 Lund,
Sweden
+46 46 2126534
per.hyttfors at sonyericsson.com
(MSN/E-mail)
___________________________________________________________
The
information in this email, and attachment(s) thereto, is strictly confidential
and may be legally privileged. It is intended solely for the named recipient(s),
and access to this e-mail, or any attachment(s) thereto, by anyone else is
unauthorized. Violations hereof may result in legal actions. Any attachment(s)
to this e-mail has been checked for viruses, but please rely on your own
virus-checker and procedures. If you contact us by e-mail, we will store your
name and address to facilitate communications in the matter concerned. If you do
not consent to us storing your name and address for above stated purpose, please
notify the sender promptly. Also, if you are not the intended recipient please
inform the sender by replying to this transmission, and delete the e-mail, its
attachment(s), and any copies of it without, disclosing it.
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple