[Standards-JIG] JEP-0060 Publisher Model - nodehirarchy permissions

[Brian Raymond]

On 5/30/06 4:14 PM, "Peter Saint-Andre" <stpeter at jabber.org> wrote:

Deleted..
> 
> The fact that a NodeID can have semantic meaning does not imply that the
> only form of semantic meaning is hierarchical. For instance, in PEP we
> have NodeIDs like "http://jabber.org/protocol/tune" -- that has semantic
> meaning ("this is a node for this user's music info") but it does not
> have hierarchical meaning.
> 
> If folks would like me to add some hardline text to the spec about not
> depending on the (seeming) structure of the NodeID to enforce hierarchy
> then I would be happy to do so. Probably the examples need to be changed
> as well (I was lazy about NodeID examples in the spec).
> 

I initially thought mentioning that a node ID could have a semantic meaning
was a nice touch because there is some utility in it for some cases. It
seems that the names of the nodes get a lot of people wrapped around the
axle so I agree it's worth making the point in the JEP that the ID must not
enforce hierarchy. 

I found the same thing happened around the office on some of the draft
PubSub work I'm doing. In my case all of my examples use a node ID that
implies a tree structure but people kept focusing on that for the structure
vs. the node configuration with a defined parent, a collection node.

- Brian