[standards-jig] comments on JEP-0060

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Jan 17 20:10:28 UTC 2003

"Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com> wrote on 17-1-
2003 21:00:22: 
>I would disagree that x:data makes JEP-0060 less generic.  It is a
>design decision, but a decision is necessary.  Nodes need 
>configuration, and x:data does a fairly handy job of it. Some LCD 
>(lowest common denominator) needs to be agreed upon, or there will be 
>little hope for interoperability.

As PGM stated the x:data form can be *any* x:data form. Basically that 
means it's only humanreadable. That's a very narrow view I think. 
Again, I have nothing against x:data and it's a very good tool from the 
job for jabber-users who want to create topics etc. by hand. But it is 
*not* generic PubSub, let alone that it actually makes it *more* 
generic. This is because you can have a PubSub server without it. 
Putting this in the spec. is like making the config files jabberd uses 
a requirment for implementing a jabber server! 

The generic PubSub protocol *is* the LCD, x:data can be the LCD of the 
layer on top of that if you like. The important thing is that is does 
not apply to all cases/implementations, so I shouldn't be in the spec. 
Making it mandatory is an even worse idea. 

>IMO, x:data is a good LCD.  x:data is a good balance between
>human-readable and machine-readable requirements, it's Jabber-centric
>(as is this Pub/Sub spec), it's "ACTIVE", and it's supported by a fair
>number of clients and components.

I don't see how x:data is machinereadable unless you have some very 
fancy AI or if you know exactly wich fields are in the form. If you 
standardize on wich fields to use (from what PGM says this is not the 
case I think) why use x:data at all? 

>I can see your point on the difference between "Nodes MUST be
>*configured* using x-data" and "Nodes MUST be *configurable* using
>x-data", though.  If the publisher can support other configuration
>mechanisms *in addition to* x:data, that's fine with me, and is 
>probably acceptable to the Council as well.

I don't see why my PubSub server should have the ability to communicate 
with humans. Sure it's nice on some occasions but why make it a 
requirment? And why would the Council want to restrict my choices like 

IMHO it should be taken out of the JEP, or it should be made very clear 
that it's an example of an implementation. Maybe the <configure/> 
element could be reserved for x:data use, though I wouldn't mind making 
it an element for generic use. 

Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list