[Standards-JIG] JEP-0060 PubSub: Modifying Node/Collection Associations and other issues.
stpeter at jabber.org
Mon Jun 5 18:45:39 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
>>> 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
>>> 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
> 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?.
>>> 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.
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards