[Standards-JIG] JEP-0060 PubSub: Modifying Node/Collection Associations and other issues.

Peter Saint-Andre stpeter at jabber.org
Mon Jun 5 17:47:08 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Version 1.8pre18 is in progress, some comments on discovery...

> Bob Wyman wrote:

>>>             I propose that we expand (yes, expand?) JEP-0060 to include
>>> some new sections and modify the existing Section 9.5:
>>>
>>>  
>>>
>>>             9.X  Discovering the Nodes in a collection

In my working copy, I've moved the discovery-related text and examples
to the Entity Use Cases section of the document.

>>> Discovering the Nodes in a Collection:
>>>
>>>             It appears that the pubsub#leaf_nodes field of a collection
>>> contains: ?'The leaf nodes associated with a collection?. However, other
>>> than an indirect reference at the end of Section 9.5 and a brief
>>> appearance in Section 16.4.3, this very important attribute is not
>>> discussed in the document and no examples demonstrate its use. I believe
>>> it would be appropriate to provide an example of ?Discovering the Nodes
>>> in a Collection? which would demonstrate querying for and reading the
>>> pubsub#leaf_nodes field. 

In looking again at the "Discover Nodes" use case, I see that Peter
Millard intended this to apply to node hierarchies implemented by means
of collection nodes. So I think that service discovery would be the
preferred means of discovering nodes in a collection. But then the
question arises: what if a service does not implement disco-based
discovery of child nodes? I have changed the requirement level here from
MAY to SHOULD, but I think it needs to be MUST (i.e., *if* a service
implements node hierarchies via collection nodes, it MUST enable
entities to discover child nodes by means of service discovery). If we
don't do that, then we would need to discover child ("associated") nodes
by means of node meta-data, which seems decidedly sub-optimal (both in
using node meta-data to find child nodes and in having two different
ways to do the same thing).

>>> Also, it would appear that even though the
>>> field is called ?leaf_nodes? that it can contain either leaf-nodes or
>>> collection-nodes. (Collections contain **either** leaf-nodes or
>>> collection-nodes?) Thus, the field should probably have been called:
>>> ?child_nodes,? ?contained_nodes,? or simply ?nodes.?
> 
> True, that is confusing. How about "associated_nodes"? Somehow the
> language of parent and child bothers me a bit in relation to pubsub, but
> I'm not sure why.

I know think "child node" is fine so I've changed the relevant
configuration options to be:

pubsub#children
pubsub#children_max
pubsub#children_association_policy
pubsub#children_association_whitelist

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEhG4bNF1RSzyt3NURAq2WAJ9cIqnsMCen00PKUdvZ6CSjxek3zACeJVqe
LOnm6FO/rDaxZucdVxcBaY4=
=IFBv
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060605/0281efa2/attachment.bin>


More information about the Standards mailing list