mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-28 04:02:20 -05:00
Typo: metadata is one word; for inbox/
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
parent
660ff16274
commit
7f87f07e17
@ -183,7 +183,7 @@ END:VCALENDAR
|
||||
|
||||
<section2 topic='Calendar Nodes' anchor='datamodel-nodes'>
|
||||
<p>A calendar node contains calendar items that represent calendar components within a calendar. A calendar node is manifested to entities as a publish-subscribe node identified by a NodeID. A calendar node MUST report the '&NS;' feature &VNOTE; in the result of a 'disco#info' query. A calendar service MUST persist items for a calendar node.</p>
|
||||
<p>A calendar node can be created through provisioning (i.e., automatically created when a user's account is provisioned), or it can be created with the publish-subscribe <create/> request (see section <link url='#create'>Creating Calendars</link>). It can be useful for a user to create additional calendars (e.g., soccer schedule) or for users to share a calendar (e.g., team events or conference rooms). However, note that this specification doesn't define the purpose of calendar nodes. Users may use the 'pubsub#title' and 'pubsub#description' fields in node meta-data to find out what a calendar node is for.</p>
|
||||
<p>A calendar node can be created through provisioning (i.e., automatically created when a user's account is provisioned), or it can be created with the publish-subscribe <create/> request (see section <link url='#create'>Creating Calendars</link>). It can be useful for a user to create additional calendars (e.g., soccer schedule) or for users to share a calendar (e.g., team events or conference rooms). However, note that this specification doesn't define the purpose of calendar nodes. Users may use the 'pubsub#title' and 'pubsub#description' fields in node metadata to find out what a calendar node is for.</p>
|
||||
<p>Calendar nodes MUST only contain calendar items. This ensures that entities do not have to deal with non-calendar data in a calendar node.</p>
|
||||
</section2>
|
||||
|
||||
@ -331,7 +331,7 @@ END:VCALENDAR
|
||||
<!-- == Node Information ================================================= -->
|
||||
|
||||
<section2 topic='Node Information' anchor='disco-node'>
|
||||
<p>A calendar service MUST also allow entities to query individual nodes for the information associated with that node. A calendar service supporting the features described in this specification MUST include "&NS;" &VNOTE; as a feature in the "disco#info" result for a calendar node. It MUST NOT include the feature in the result for a non-calendar node. The "disco#info" result MAY include detailed meta-data about the node as described in section 5.4 of <cite>XEP-0060</cite>.</p>
|
||||
<p>A calendar service MUST also allow entities to query individual nodes for the information associated with that node. A calendar service supporting the features described in this specification MUST include "&NS;" &VNOTE; as a feature in the "disco#info" result for a calendar node. It MUST NOT include the feature in the result for a non-calendar node. The "disco#info" result MAY include detailed metadata about the node as described in section 5.4 of <cite>XEP-0060</cite>.</p>
|
||||
<example caption='Entity queries a node for information'><![CDATA[
|
||||
<iq type='get'
|
||||
from='francisco@denmark.lit/barracks'
|
||||
@ -341,7 +341,7 @@ END:VCALENDAR
|
||||
node='princely_musings'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Service responds with information and meta-data'><![CDATA[
|
||||
<example caption='Service responds with information and metadata'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
@ -353,7 +353,7 @@ END:VCALENDAR
|
||||
<feature var='urn:xmpp:tmp:calendar:0'/>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#meta-data</value>
|
||||
<value>http://jabber.org/protocol/pubsub#metadata</value>
|
||||
</field>
|
||||
<field var='pubsub#type' label='Payload type'>
|
||||
<value>urn:ietf:params:xml:ns:xcal</value>
|
||||
|
@ -158,7 +158,7 @@ pubsub-itemid = 1*( unreserved / pct-encoded / sub-delims )
|
||||
|
||||
<p>The query component provides a way to refer more specifically to
|
||||
data associated with the target. Possible values for URIs referring to
|
||||
nodes are: "meta-data" and "last-item".</p>
|
||||
nodes are: "metadata" and "last-item".</p>
|
||||
|
||||
<p>If an authority ("authxmpp") is given in the URI string, this indicates
|
||||
the user the application should connect as. Otherwise, the application
|
||||
@ -174,8 +174,8 @@ pubsub-itemid = 1*( unreserved / pct-encoded / sub-delims )
|
||||
<![CDATA[xmpp.pubsub:pubsub.shakespeare.lit/princely_musings/]]>
|
||||
</example>
|
||||
|
||||
<example caption="A URI referring to the meta-data of a node">
|
||||
<![CDATA[xmpp.pubsub:pubsub.shakespeare.lit/princely_musings/?meta-data]]>
|
||||
<example caption="A URI referring to the metadata of a node">
|
||||
<![CDATA[xmpp.pubsub:pubsub.shakespeare.lit/princely_musings/?metadata]]>
|
||||
</example>
|
||||
|
||||
<example caption="A URI referring to the last published item of a node">
|
||||
|
Loading…
Reference in New Issue
Block a user