[Standards-JIG] JEP-0060 Publisher Model - nodehirarchypermissions

Bob Wyman bob at wyman.us
Fri May 26 15:40:43 UTC 2006

Jean-Louis Sequineau wrote:
> I strongly agree with Bob's statement. In a properly designed
> pubsub brokering system Node IDs must be opaque.
	The hierarchical "topic names" are a residue of the old
"topic-based" form of publish/subscribe. In those systems, a subscription's
expressiveness was limited to simply specifying a topic name. Users would
subscribe to a topic and then receive everything published to that topic.
For instance, a mailing list, like this list, represents a form of
topic-based publish/subscribe. Users are able to subscribe to the list and
will receive ALL messages published to the list.
	In order to make it easier for users to select the topics to
subscribe to, pubsub systems have typically used topic-names that are
meaningful to users. Thus, one might have a topic like
"standards-jig at jabber.org" since that is reasonably transparent. However, it
often arises that folk want only a subset of information published to a
topic and wish to avoid unnecessary publications. Thus, we'll do things like
create a sub-topic like: "standards-jig/JEP-0060 at jabber.org" that would only
publish a subset of the messages published to the main topic. But, then
other users will have a different way of viewing the world and will want to
receive all messages related to pubsub related protocols. This might cause
the creation of a topic like "standards-jig/pubsub at jabber.org". Given these
three topics, messages concerning PEP or JEP-0060 might end up being
published to all three of the topics. Thus, we see that we don't really have
a hierarchy. Rather, the classification system is best represented as a
	Unfortunately, as we come to understand areas of interest better
over time, it is likely that we'll find ourselves creating new topics to
better map our understanding of structure of concepts and we'll end up
wanting to move topics from one point in the graph to another. 
	Historically, pubsub systems that have embedded structural or
classification information in their topic names have found that it is very,
very difficult to implement reorganizations since either there is no
mechanism to notify subscribers of the changes in structure or the protocols
to do so are very expensive and unreliable. Thus, we find that it is much,
much more robust to use opaque topic names and provide a different mechanism
for expressing the structure of the topic-space.
	For those who are really into this subject, I suggest that you look
at the work which has been done in ISO on "topic maps" and classification
systems. See the documentation of XML Topic Maps at:
	The names chosen by XTM are a bit confusing but, what we have in
JEP-0060 as a nodeID for a topic should be treated as a "Subject Indicator."
Thus, it should be an unambiguous identifier for a particular subject or
topic. (In XTM systems, the "subject indicator" is often just a unique URI
or URN). In XTM systems, the "structure" of the space of "subjects" is
provided via the "topic." In such a system, the "topic" is metadata for the
subject. Now, ignoring the confusing names, the important point is that the
identification of the unique thing (the topic) is distinct from the
meta-data that describes that thing's relationship to other things. This
means that the same unique identifiers can be reused in multiple places in
the overall structure and it is even possible to share unique names across
otherwise incompatible systems. (e.g. A "French" and "English" system could
both agree to use the same subject-indicators even though they use very
different classification structures and names for various levels in their
	As Jean-Louis points out, we have learned over and over again, when
implementing pubsub systems in the past, that "topic-names" with embedded
structural information make life exceptionally difficult for all concerned
even though such systems are terribly easy to build and usually appear to be
useful early in their lives. Over time, however, the nightmare grows... We
can avoid this problem with JEP-0060 by ensuring that everyone knows that
the NodeIds associated with Topics MUST be opaque.

	bob wyman

More information about the Standards mailing list