Re: [Simple] XCAP and its problem with Namespaces caused by using only the XML fragment body.
Jari Urpalainen <jari.urpalainen@nokia.com> Wed, 17 August 2005 08:05 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5IvC-0004S5-In; Wed, 17 Aug 2005 04:05:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Iv9-0004Rs-Lr for simple@megatron.ietf.org; Wed, 17 Aug 2005 04:05:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13930 for <simple@ietf.org>; Wed, 17 Aug 2005 04:05:09 -0400 (EDT)
Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5JUd-000726-LF for simple@ietf.org; Wed, 17 Aug 2005 04:41:53 -0400
Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j7H83xG15547; Wed, 17 Aug 2005 11:03:59 +0300 (EET DST)
X-Scanned: Wed, 17 Aug 2005 11:03:41 +0300 Nokia Message Protector V1.3.35 2005042208 - RELEASE
Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j7H83fdF022469; Wed, 17 Aug 2005 11:03:41 +0300
Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Yuot5b; Wed, 17 Aug 2005 11:03:40 EEST
Received: from kusti.research.nokia.com (mgw.research.nokia.com [172.21.56.13]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j7H83eK23667; Wed, 17 Aug 2005 11:03:40 +0300 (EET DST)
Received: from xitami.research.nokia.com (xitami.research.nokia.com [172.21.50.105]) by kusti.research.nokia.com (Postfix) with ESMTP id F310193B6A; Wed, 17 Aug 2005 11:03:39 +0300 (EEST)
Received: from hed034-145.research.nokia.com (hed034-145.research.nokia.com [172.21.34.145]) by xitami.research.nokia.com (Postfix) with ESMTP id C660771D; Wed, 17 Aug 2005 11:03:39 +0300 (EEST)
Subject: Re: [Simple] XCAP and its problem with Namespaces caused by using only the XML fragment body.
From: Jari Urpalainen <jari.urpalainen@nokia.com>
To: ext Jonathan Rosenberg <jdrosen@cisco.com>
In-Reply-To: <43028B85.5060100@cisco.com>
References: <1AF90E65795A3D45AA116B9264B4DAAF029D86E6@SELDMSX01.corpusers.net> <43028B85.5060100@cisco.com>
Content-Type: text/plain
Date: Wed, 17 Aug 2005 11:03:39 +0300
Message-Id: <1124265819.11970.26.camel@hed034-145.research.nokia.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4)
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Content-Transfer-Encoding: 7bit
Cc: "Hyttfors, Per" <Per.Hyttfors@sonyericsson.com>, simple@ietf.org
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Sender: simple-bounces@ietf.org
Errors-To: simple-bounces@ietf.org
On Tue, 2005-08-16 at 20:57 -0400, ext Jonathan Rosenberg wrote: > inline. > > Hyttfors, Per wrote: > > > 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. > > The client doesn't need the whole document; it just needs the portion of > the document above the element that has been fetched, in order to know > the namespace bindings that are in scope for the element that is being > fetched. > > I'm assuming that you have in mind an application where the client > doesn't normally store the whole document, for example a cell phone > where I want to retrieve portions of my buddy list one buddy at a time. > > As such, one solution is to fetch the whole document at startup, get the > namespace bindings and etag, and dump the document. Then, subsequent > GETs are conditional against the etag, and so the client can get the > information it needs and use the cached namespace bindings. > > 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. > > Some other thoughts are: > > 1. an xcap extension that allowed to specifically query for the > namespace bindings in scope for a particular element > > 2. change xcap so that what is returned is an xml fragment that includes > additional information on the namespace bindings in scope > > 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 > I suppose this question has come from OMA people. An XPath way of doing this could be GET ....~~/root/namespace::*, i.e. namespace axis could be used to request all the in-scope namespaces of some element. An XCAP extension should then describe this BNF extension as well as the payload format. br, Jari _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
- [Simple] XCAP and its problem with Namespaces cau… Hyttfors, Per
- Re: [Simple] XCAP and its problem with Namespaces… Jonathan Rosenberg
- Re: [Simple] XCAP and its problem with Namespaces… Jari Urpalainen
- Re: [Simple] XCAP and its problem with Namespaces… Dean Willis
- Re: [Simple] XCAP and its problem with Namespaces… Joel M. Halpern
- Re: [Simple] XCAP and its problem with Namespaces… Jari Urpalainen
- RE: [Simple] XCAP and its problem with Namespaces… Hyttfors, Per
- Re: [Simple] XCAP and its problem with Namespaces… Jonathan Rosenberg
- Re: [Simple] XCAP and its problem with Namespaces… Jari Urpalainen
- Re: [Simple] XCAP and its problem with Namespaces… Sebastian Ley