[standards-jig] comments on JEP-0060
mass at akuma.org
Sat Jan 18 02:19:31 UTC 2003
Joe Hildebrand wrote:
>/me gets caught up in the burgeoning flame war.
>sorry in advance...
>>>Like JoeH said, if we establish a standard for naming var's in
>>>these xdata forms, then it's completely machine readable.
>>So at least you admit there is no such standard. (1)
>JEP-0053 is at least a beginning. Please comment on your perceptions of its
>inadequacies in a separate thread, but suggesting that there is *no*
>standard is a little... disingenuous.
JANA as a concept is fine (that is all this JEP documents), but there
needs to actually be a standard for fields. Here is an example of what I
am looking for.
- what field names are reserved for foundation (i.e. official)
- what field names are usable for different vendors, or for
- what field names are suitable for experimentation (i.e.
non-deployment, fixed environment names)
For standards-track and informational JEPs, valid field values and an
appropriate description must be documented in addition to the field
name. Other attributes and child elements of x:data fields are assumed
to be for basic user presentation, and must not be required to be
certain values. A JEP should not limit any x:data forms to only contain
a specific set of fields, nor should it limit the title or instructions
to a certain value.
It would be ideal if forms as a whole MUST have a unique method of
retrieval and/or a unique way of identifying the result as a specific
'type' of form for machine interpretation or custom user agent behavior
(such as hard-coding layout of forms corresponding to features wanted in
the client). Examples of this would be requesting a form via a message
or IQ wrapped in a certain namespace. (Note: A form identifier at the
top level would have been a nice feature in JEP-0004, but its final now,
so I consider that ship sailed)
All of this needs to be attached to the appropriate standard (e.g.
x:data) as a MUST for compliance.
As another nicety, JANA should also allow vendors to document custom
field names and the corresponding values and description/places within
particular JEPs without going through the full informational JEP process.
>Or a programmer who has looked at the form that an implementation uses, and
>applies a little bit of string-matching logic, and holds a club over the
>head of the server implementor not to change the interface. Or there's a
>document that the implementor uses as a contract with the users of that
>service. I've written lots of programs that know how to fill out HTML forms
>on the web. I didn't have to write an AI to do it. I just needed to know
>what fields that particular form was expecting.
This is coding against a particular 'implementation', one particular
form or set of forms on a particular website. Write your script for
amazon.com, then try and use it against Barnes and Nobles' site without
any changes. This is fine for particular implementations, but not
acceptable for standards.
>No, but you need a generic protocol for specifying which name/value pairs
>you need filled out. You might want some type information for redundancy
>I bet by the time you are done defining that protocol, it will look
>suspiciously like x:data.
>Now, sometimes users *will* want to be able to configure a node manually.
>In that case, you'll have to create a way of prompting a user for the data
Actually, I like x:data, for the same reasons I think XML-RPC is a
valuable tool on top of XML. if I could go back in time I would separate
out all UI aspects into a separate namespace, but until I finish my time
machine I am happy to use it.
>>*sighs* I guess I have to keep saying this over and over. I'm NOT
>>opposed to using x:data with PubSub. In fact, it's brilliant! For
>>*some* uses of PubSub. I've never said anywhere that humans
>>pubsub. I've never said you can't write a JEP on using x:data with
>>PubSub. In fact I've even suggested it! Where are you getting
>>from? I hope it doesn't have to do with your own remark above.
>No, but you are saying that you don't think *this* jep should include
>x:data. I thought that PGM's offer to include this language should have
>been good enough:
>* Any node configuration available MUST be done using the x-data protocol.
>What this means is that in some cases of pubsub, a node MAY not have any
>configuration. In those cases, the server MUST respond to the iq-get for the
>config form with an error-501: Not Implemented.
>but I didn't see any comment from you on that. What about changing MUST to
>SHOULD? Would that be acceptable to you? Then you could configure the
>nodes with whatever protocol you want, but people that want to interoperate
>can still do so.
I think it should read "Any node allowing configuration MUST allow
configuration to be done with the x:data protocol as a minimum".
I also think that many of the 'must' requirements for features should be
'should' requirements, but that is a different discussion.
More information about the Standards