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

[Peter Saint-Andre]

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

More notes from the field...

> Bob Wyman wrote:

>>> Associating Nodes with Collections:
>>>
>>>             There are three interesting use-cases which are not already
>>> covered well by the existing Section 9.5:
>>>
>>> 1.       Associating an existing node with a collection.
>>>
>>> 2.       Disassociating an existing node with a collection.
>>>
>>> 3.       Moving a node from one collection to another (i.e. 1 and 2
>>> together)
>>>
>>>             Other than the discussion in Section 9.5 of associating
>>> newly created nodes with Collections and some inferences in other
>>> places, JEP-0060 is largely silent on the subject of associating nodes
>>> with collections. This should be fleshed out.
>>>
>>>             It appears that one can associate a node with a collection
>>> by modifying the ?leaf_nodes? field of the collection. Alternatively,
>>> one can modify the ?pubsub#collection? field of a node. However, these
>>> mechanisms are only mentioned in terms of disassociating a node from a
>>> collection (see end of Section 9.5). We should have some discussion of
>>> the ?positive? use of these mechanisms to associate a node with a
>>> collection and we should probably have at least one example (yes, more
>>> text?).
>>>
>>>             Given these two mechanisms for modifying the association of
>>> a node with a collection, it would appear that the answer to bernards?s
>>> questions concerning ?moving? a node, would be that to do so, you must
>>> use one of these mechanisms. (modify pubsub#leaf_nodes of the
>>> appropriate collections or pubsub#collection of the node being moved.)

I've added those sections to my working copy.

>>>             However, there are some serious problems created here due to
>>> the support for implementation-specific ?semantic meaning? in node ids.
>>> The problem is that modifications to collections would require the
>>> regeneration (changing) of NodeIDs if those NodeIDs have semantic
>>> meaning. 
> 
> If the semantic meaning is intended to reflect hierarchy, yes. (BTW, I
> will modify the examples to remove all suggestion of hierarchy in the
> semantic meaning.)
> 
>>> For instance, if an implementation held that ?/? in a NodeID
>>> indicates hierarchy, then if I moved the node with the NodeID ?foo/bar?
>>> into the ?mumble? collection, it would be necessary to generate a new
>>> NodeID ( perhaps: ?mumble/bar?) and delete the old NodeID. This is very
>>> problematic since it means that the act of ?moving? the node would kill
>>> any existing subscriptions to that NodeID? 
> 
> Yes, that is very problematic indeed.

I've removed references to encapsulating hierarchy in NodeID semantics
and stipulated that implementations MUST NOT do that.

>>> It would appear that implementations that supported ?semantics in
>>> NodeIDs? would, by definition, be incapable of permitting a single node
>>> to appear in more than one collection since a node can only have a
>>> single NodeID? (Unless some complex syntax for NodeIDs was defined to
>>> indicate membership in more than one collection (?(foo|mumble)/bar?
>>> might work for the example above.)
> 
> Again, I don't think it's right to conflate semantic meaning with
> hierarchical structure. But in the case where the semantic meaning
> attempts to encapsulate hierarchy (bad!), then you would be right.

See above on NodeID semantics.

>>> Issues with 9.5 (concerning default configurations)
>>>
>>>             As written, it would appear that Section 9.5 creates a
>>> conflict with the normal means of creating a node.
>>>
>>> 1.       Because an implementation can ?generate? NodeIDs if it
>>> attributes semantic meaning to NodeIDs, and since it is not possible to
>>> discover if an implementation has such a policy (there is no IQ value
>>> that describes the policy), 
> 
> It would be good to specify how this can be discovered.
> 
>>> it would appear that one should never
>>> provide a NodeID in a request to create a node within a collection. One
>>> must always use ?Instant Nodes? (see: Example 107) in this case and thus
>>> a system that supports NodeID semantics MUST always support Instant
>>> Nodes. Also, in order to support clients that are expecting
>>> implementations that support Semantics in NodeIDs, all implementations
>>> are essentially forced to support Instant Nodes.
> 
> That doesn't seem good.

See above on NodeID semantics.

>>> 2.       It appears impossible to create a node in a collection if that
>>> node is to have a ?default? configuration. This is because the mechanism
>>> for creating a node in a collection requires that a non-empty
>>> <configure/> element be used yet Section 8.1.2 says that to create a
>>> node with a ?default configuration,? one must use an empty <configure/>
>>> element to indicate that you wish a default configuration. It would seem
>>> that we would have to either expand Section 8.1.2 to say that you must
>>> either use an empty <configure/> element or, in the case that you are
>>> creating a node in a collection, you must use a <configure/> element
>>> that only contains a value for ?pubsub#collection?. 

Done.

>>> General issues:
>>>
>>>             It should be clear to anyone reading the discussion of
>>> collections that the support for ?semantics? in NodeIDs (described in
>>> 12.12) makes things much more complex than they might otherwise be. This
>>> is particularly the case since a client has no means to discover what
>>> semantics might be associated with the NodeID patterns?. 

See above on NodeID semantics, and the text in 18.pre18.

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

iD8DBQFEhHvSNF1RSzyt3NURApjoAJ9pA3kS3kEufq7s+qBH0BvuDXArNgCbBV+U
6GGH+qB5bdiiVqBfn/YDh5c=
=cHDM
-----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/7c886163/smime.bin