[standards-jig] comments on JEP-0060
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-
>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.
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the Standards