[standards-jig] JEP0024 wildcards
timbeau_hk at yahoo.co.uk
Sat Jul 13 17:31:09 UTC 2002
Thanks for a rapid reply.
>The French news based issue is an application issue. If you need to
>distinguish between countries of origin, and or Language, then ( I would
>) introduce that into your hierarchical namespace format.
I was just pointing out that the document saying a sub uses 'home' is
misleading for the reader and could imply sub-relative namespaces. Heaven
>> 2) Data may have more than one 'namespace'...in fact NEWS especially has the
>> possibility of tens of classifications per story - e.g. politics, drugs, US,
>> police, Washington, Civil Rights, election etc. The alternative is to have
>> embedded codings as payload data and filter after the delivery, which many
>> systems do already with the obvious bandwidth and processing implications on
>> the last mile.
>> I would suggest to avoid confusion, that the news namespace be altered in
>> JEP0024 to suggest something that would work as a more unique namespace, if
>> only one namespace can be given to data by the publisher. E.g.
>> Alternative is duplicating messages with different namespaces or multiple
>> namespaces sent by the publisher...
>> "news:[politics|US|Police|Washington|drugs|heroin|crime]:wires"? The pub:sub
>> entity would then have to filter on this, or the client filters at the other
> I think you are hitting on a idea that has been thrown arround - the
> idea of possibly "wildcarding" namespaces that are subscribed too. So
> far the reason that this has been avoided is the difficulty that this
> would bring to the implementation of the component.
> "Implementation" - I hear you say! Yes - we had to start somewhere. If
> a reasonable set of rules by which a sophisticated namespace or hierachy
> matching could be applied ( for instance an XPath style expression ),
> that didn't have the prospect of making the scalability of the pubsub
> component a problem, then I'd be interested.
Wildcards exist within existing pub-sub namespace paradigms, so Jabber would
be at a disadvantage if this was not supported. (!)
However, this is separate as news:[politics|trade]:UK would not have
news:sport:UK in it, for example and thus is not the same as news:*:UK
This is as much an issue for publishers, especially those who cannot
classify their data as one would classify a beetle.
The alternative is to have in-payload codes as is done now.
>> The centralised filtering allows for lower bandwidth last mile dumb
>> streaming to the client device but puts a greater load on the server to sift
>> multiple namespace combinations. Server should have right to refuse.
>> With the current framework, we are only able to send multiple messages from
>> the publisher to achieve namespace granularity, so placing an assumption on
>> the architecture. If we allow "polynamespacing" then we have further choices
>> of filtering at server or client. This allows us to decide trade-offs of cpu
>> and bandwidth.
> Ok - but these are tied to a decision above. Do we allow multiple
> tagging of namespaces to the published data, or do we allow
> subscriptions to be more inteligent ( wildcards etc.) ? Need to think
> about that one.
I would prefer all options - wildcards, polynamespaces and multiple
>> A mobile phone streamer, for example, would prefer polynamespace filtering
>> at the server. The publisher may like to have polynamespace publishing (once
>> only per item), but intermediate caches with terrestrial, high powered
>> data-hungry clients would perfer to have client-side filtering by streaming
>> over a few multicast channels.
>> (It may be worth warning namespacer's to be aware of the implications of
>> multicast delivery on namespace allocation)
> This is very applicaiton specific - a publisher/subscriber subscription
> relationship would tune their relationship ( ie. the agreement of what
> namespaces meant ) to meet their needs. The key is to ensure that the
> specification is open enough to make this possible.
Publishers should not have to get into an agreement with subscribers about
namespaces beyond telling them what the scheme is. Apart from breaching one
of the basic tenets of pub:sub - detaching publisher from direct
relationships with subscribers - it would cause chaos when subscribers have
conflicting needs due to their delivery architectures or data managers with
their own ideas as to naming schemes.
Getting the spec open enough to allow subscribers to ask for data in the way
that suits them is the basis for my suggestions. At the moment, a single
linear namespace for publishing is keeping things too narrow.
>> 4) Finally and trivially..I would like to confirm if namespaces can be
>> 'sticky' within a node, such that a headline, body and other information
>> (subject codes) have the same namespace without repeating it for each field.
>> If not, it would be preferable to have some form of "~:" or other operator
>> to say "whatever, plus...". Forgive me if this is already sorted, but it was
>> not clear to me (my fault) from the short data payloads of the examples in
> If I understand the question correctly then published data does inherit
> the namespace with packets like this:
> SEND: <iq type='set' to='pubsub.localhost'
> from='publisher.localhost' id='s1'>
> <query xmlns='jabber:iq:pubsub'>
> <publish ns='foo'/>
> namespace published to is foo and the namespace specified on the payload
> is foo.
> <foo xmlns='foo'>bar</foo>
> Maybe DJ has something to add to all of this :-)
errr...sorry, that has foo in both items so hard to tell...:-)
I was more thinking of
so that to get the prices only you subscribe to
publisher:exchange:stock:prices without getting swamped by orderbook
information or the whole namespace having to be put into the information
There is no need to look at payloads and no confusion with sub-entities
having totally different namespaces from the parent.
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
More information about the Standards