[Standards-JIG] JEP-0060 Feedback and questions.

Brian Raymond brian.raymond at je.jfcom.mil
Sat May 27 04:55:23 UTC 2006

On 5/25/06 10:13 AM, "Ralph Meijer" <jabber.org at ralphm.ik.nu> wrote:

> On Thu, May 25, 2006 at 12:45:18AM -0400, Brian Raymond wrote:
>> 1. Section 9.2: If an entity is subscribed to a collection node with type
>> "items" and the server can return payload with a subscription notification
>> can the server deliver the payload? The JEP states that the item if MUST be
>> identified in the response however it isn't clear weather or not the payload
>> can be returned as well.
> I cannot really parse your question here. Are you referring to example
> 199 in section 9.6? (I'm referring to the 1.8pre17)

Yes I was referring to how a server returns notifications regarding
collection node subscriptions if the server supports return payloads with
> But since I'm reading this anyway: Peter, I haven't looked at this
> before but it seems to me that this is wrong. If you have node that is
> configured to be transient and notification only, there would be no
> <item/> element in the notifications. How would this work with
> collections now?
> The are two possible choices for the node attribute on the <items/>
> element in a notification from a collection.
>  1) The original node to which the item was published.
>  2) The node to which the receiver was subscribed.
> Option #2 seems problematic, because you cannot use the item ids to
> retrieve the item later (you have no idea which node it came from).
> Option #1 has the problem that the receiver cannot immediately see which
> subscription yielded that notification. For the subscription ID
> use-case, example 83 shows how to use SHIM to send along the subids that
> yielded the notification. We could add a similar header for collection
> nodes.
> Ideas?

Option 1 looks like it will work, however I think we do need an example for
collections clarifying how you set the node attribute and use SHIM headers.
>> 2. Section 6.4: An entity may retrieve all items associated with a node by
>> requesting the node with no qualifiers. The following might be in the spec
>> but I might have overlooked it, however what is the behavior if that request
>> is made against a collection node?
> Collection nodes do not support item retrieval as they can never persist
> items themselves. The prose above example 66 makes mention of this, but
> maybe we should make this more explicit in section 9. In any case, the
> result should be as in example 66.

You are right, they don't support item retrieval however I was wondering how
I go about requesting all of the direct children of a collection node. I
used Section 6.4 to point out how an entity would request the children of a
node, which means they get all of the items. What I don't see is how I would
structure a similar request to get all children of a collection node, it
sounds like there is no direct equivalent.  You point out below that one
needs to use service discovery (disco#items) to retrieve all of the children
of a collection node.
>> 3. I thought I previously verified that an entity can request the entire
>> subtree, including all items (with payload) and nodes from a collection node
>> however I can't locate any information on that now, is this possible?
> A disco#items on a collection node yields the nodes it contains.
> A disco#items on a leaf       node yields the items it contains.
> The latter excludes the payload. That may be retrieved using the regular
> item retrieval protocol.

More information about the Standards mailing list