Yes I've been thinking the same thing since this thread started. XCAP seems
to be to XML what XDI Messaging is to XDI itself.
For example, if a card in the back-end was represented like this: (In X3
Simple format)
$cardid!2273829
+name
"My Card"
+name+issuer
"Higgins"
+image
"AB762F672F3BFA7BFE672FB76BAEFB2624917...."
$d$lastupdate
"2009-04-08T12:13:14Z"
+claims
/
+(http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname)
+name
"First Name"
+description
"First Name"
$value
"Drummond"
... other claims here ...
Then you could update a part of that card by sending an XDI message like
this:
=sender
$mod
/
$cardid!2273829
+name
"My Renamed Card"
You just update the part of the data you need instead of sending the whole
thing.
Markus
On Sat, Apr 18, 2009 at 1:42 AM, Drummond Reed
<[email protected]>wrote:
> I’ve been silent on this thread because I’ve been heads-down on behalf of
> the Information Card Foundation on preparations for RSA, but I wanted to pop
> up long enough to say that the OASIS XDI TC is very interested in seeing XDI
> used as a back-end card sync protocol for the same reasons Antoine mentions
> using XCAP.
>
>
>
> The XDI TC studied XCAP early in our evolution, and I admire its design. In
> many ways XDI is like “XCAP for RDF”, which means it has the same generic
> REST operation capabilities, plus semantic capabilities beyond that of XML,
> some of which are very well suited to cross-domain data sharing and
> synchronization.
>
>
>
> Markus, as the lead developer of XDI4J, is intimately familiar with XDI.
> You can check out his XDI demonstration utilities based on XDI at
> http://graceland.parityinc.net/xdi-validator/Other.jsp.
>
>
>
> I’m happy to provide more information after I resurface after RSA next
> week.
>
>
>
> =Drummond
>
>
> ------------------------------
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Markus Sabadello
> *Sent:* Friday, April 17, 2009 6:41 AM
> *To:* Higgins (Trust Framework) Project developer discussions
> *Subject:* Re: [higgins-dev] Enhancement proposal for the CardSync
> protocol
>
>
>
> Hi again,
>
> Hmm I see.. Sounds quite convincing. I thought it's only useful when you
> actually use XML as your backend storage.
>
> Now that I think of it again, it may really make sense to be able to update
> only a part of the card instead of always sending the whole thing. The
> question of course is, is it worth introducing the overhead of a new
> protocol/library.
>
> Alexander? Do you have any opinion on this?
>
> Markus
>
> On Fri, Apr 17, 2009 at 2:58 PM, Antoine Fressancourt <
> [email protected]> wrote:
>
> Hello Markus,
>
> Nice to share some thoughts with you on the list! Regarding the Iphone
> selector, I somehow have a problem on my computer with the Iphone
> developer certificate, and I didn't have that much time to work on it
> since your visit in Paris. But I am not the kind of guy who let things
> go that easily ;-)
>
> I have read your answer quite carefully, and I don't really agree with
> your conclusions on the use of the XCAP protocol. Indeed, in its
> typical use case, XCAP is used only to act on informations which may
> not be stored as XML files in the backend. In a presence service using
> XCAP to set filtering rules. These rules may not be stored in XML
> format. The purpose of this syntax is to reduce the length of the XML
> document sent in the requests in order to ease the transmission of the
> message and the parsing operation of the XML document when it is
> received, as the modification is clearly spotted in the XCAP URI.
>
> I understand that this may not be your first priority to date, but I
> am quite sure that the use of this protocol can ease the operation of
> the cardsync protocol later, especially on the server where XML
> parsing operations can be time consuming.
>
> Antoine
>
> 2009/4/13 Markus Sabadello <[email protected]>:
>
> > Hi Antoine,
> >
> > Nice to see you on the list :)
> > I've never heard of XCAP, but I just went through that PPT. It looks like
> a
> > great technology.. It seems to be very suitable when you have backend
> data
> > in XML format and want to expose that data.
> >
> > In the CardSync protocol however, we don't really have XML data in the
> > backend. We only use it in the protocol. RPPS stores cards in a database,
> > not as .crd files. Also, in the "Update Card" message
> > (http://wiki.eclipse.org/CardSync_JAX-RS_API#Update_ICard), the XML
> format
> > is different from the .crd format of a card.
> >
> > So I think XCAP would be overkill here. But I'm not sure, maybe Alexander
> > has a different opinion (he mostly designed CardSync).
> >
> > BTW Antoine, any news on the iPhone Selector? Did you try to build it
> > yourself?
> >
> > Markus
> >
> > On Thu, Apr 9, 2009 at 3:46 PM, Antoine Fressancourt <
> [email protected]>
> > wrote:
> >>
> >> Hello list,
> >>
> >> I am a R&D engineer from Atos Worldline, one of the companies involved
> >> in the FC² project in France. We had the opportunity and the chance to
> >> meet with Paul Trevithick and Markus Sabadello in France during a 3
> >> days meeting in April when some details about the Higgins project and
> >> the components architecture were presented to us. During this meeting,
> >> we learnt about the cardsync protocol, which is an XML document
> >> exchange using a RESTful interface.
> >>
> >> I have a suggestion to make about this protocol. In the wiki
> >> documentation, the messages exchanged to create, update or destroy a
> >> card in the cardstore. Indeed, I am a bit sceptic about the method
> >> used to update a card. From my understanding, when somebody wants to
> >> update an information on a card, he has to send the whole content of
> >> the file in XML, with the update included. It seems to me that this
> >> procedure could be enhanced by using XCAP.
> >>
> >> XCAP stands for XML Configuration Access Protocol. Basically, this
> >> protocol allows a person interested in a particular data in an XML
> >> document to access it directly. The path of the XML node in the
> >> document is mapped to an URI, which can be used to create, update or
> >> destroy the node. As I am sure this explanation is not enough for you,
> >> I can indicate you an excellent XCAP tutorial written by the principal
> >> author of the XCAP RFC.
> >> http://www.jdrosen.net/papers/xcap-tutorial.ppt
> >>
> >> Currently, this protocol is used in Telecommunication services such as
> >> Presence service or contact list management in order to maintain
> >> contact lists or user profile in a central node called the XML
> >> Document Management Server. As this server has about the same role for
> >> these services as the CardStore in the Higgins architecture.
> >>
> >> I make a suggestion here, and I would be pleased to answer your
> >> remarks or questions if you have some.
> >>
> >> Best regards,
> >>
> >> Antoine Fressancourt
> >> _______________________________________________
> >> higgins-dev mailing list
> >> [email protected]
> >> https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >
> >
> > _______________________________________________
> > higgins-dev mailing list
> > [email protected]
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev
> >
> >
> _______________________________________________
> higgins-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
>
> _______________________________________________
> higgins-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
_______________________________________________
higgins-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/higgins-dev
