0.3: updated to describe composition model

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2005 4b5297f7-1745-476d-ba37-a9c6900126ab
xep-0352-v0.2
Peter Saint-Andre 15 years ago
parent 75d1484a67
commit 8cd9ffbd6e

@ -23,8 +23,14 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>TO BE ASSIGNED</shortname>
<shortname>NOT_YET_ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.3</version>
<date>2008-06-20</date>
<initials>psa</initials>
<remark><p>Added text about composition model, and modified examples accordingly.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2008-03-03</date>
@ -247,6 +253,10 @@
<p>If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of <cite>XEP-0163</cite>.</p>
</section1>
<section1 topic='Composition' anchor='composition'>
<p>Each item published to the node is a logically separate instance of the data to be stored. It is the responsibility of the publishing and receiving entities to construct a complete view of all such items, if desired. For example, each bookmark published to a private data node is a separate piece of data, whereas the history of all items published to the node provides a complete list of the user's bookmarks. This history may include items that are republished with an existing ItemID (thus overwriting the previous version of that item).</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>Before an account owner attempts to complete the use cases defined herein, its client SHOULD verify that the account owner's server supports both PEP and the "publish-options" feature; to do so, it MUST send a &xep0030; information request to the server (or cache <cite>Entity Capabilities</cite> information received from the server).</p>
<example caption='Account owner queries server regarding protocol support'><![CDATA[

@ -23,8 +23,14 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>TO BE ASSIGNED</shortname>
<shortname>NOT_YET_ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.3</version>
<date>2008-06-20</date>
<initials>psa</initials>
<remark><p>Added text about composition model, and modified examples accordingly.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2008-03-03</date>
@ -58,14 +64,13 @@
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='storage:bookmarks'>
<item>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</storage>
<conference xmlns='storage:bookmarks'
autojoin='true'
jid='theplay@conference.shakespeare.lit'
name='The Play&apos;s the Thing'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</item>
</publish>
<publish-options>
@ -98,14 +103,13 @@
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='storage:bookmarks'>
<item id='SomeID'>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</storage>
<conference xmlns='storage:bookmarks'
autojoin='true'
jid='theplay@conference.shakespeare.lit'
name='The Play&apos;s the Thing'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</item>
</items>
</event>
@ -118,14 +122,13 @@
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='storage:bookmarks'>
<item id='SomeID'>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</storage>
<conference xmlns='storage:bookmarks'
autojoin='true'
jid='theplay@conference.shakespeare.lit'
name='The Play&apos;s the Thing'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</item>
</items>
</event>
@ -150,14 +153,13 @@
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='storage:bookmarks'>
<item>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</storage>
<conference xmlns='storage:bookmarks'
autojoin='true'
jid='theplay@conference.shakespeare.lit'
name='The Play&apos;s the Thing'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</item>
</publish>
</pubsub>
@ -170,14 +172,13 @@
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='storage:bookmarks'>
<item>
<storage xmlns='storage:bookmarks'>
<conference name='The Play&apos;s the Thing'
autojoin='true'
jid='theplay@conference.shakespeare.lit'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</storage>
<conference xmlns='storage:bookmarks'
autojoin='true'
jid='theplay@conference.shakespeare.lit'
name='The Play&apos;s the Thing'>
<nick>JC</nick>
<password>Gl0b3</password>
</conference>
</item>
</publish>
<publish-options>
@ -199,6 +200,10 @@
<p>If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the Receiving Event Notifications section of <cite>XEP-0163</cite>.</p>
</section1>
<section1 topic='Composition' anchor='composition'>
<p>Each item published to the node is a logically separate instance of the data to be stored. It is the responsibility of the publishing and receiving entities to construct a complete view of all such items, if desired. For example, each bookmark published to a private data node is a separate piece of data, whereas the history of all items published to the node provides a complete list of the user's bookmarks. This history may include items that are republished with an existing ItemID (thus overwriting the previous version of that item).</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>Before an account owner attempts to complete any of the use cases defined herein, its client SHOULD verify that the account owner's server supports both PEP and the "publish-options" feature; to do so, it MUST send a &xep0030; information request to the server (or cache <cite>Entity Capabilities</cite> information received from the server).</p>
<example caption='Account owner queries server regarding protocol support'><![CDATA[

Loading…
Cancel
Save