[standards-jig] UPDATED: JEP-0004
iain.shigeoka at messaginglogic.com
Mon Sep 16 17:22:11 UTC 2002
On 9/13/02 11:47 AM, "Ralph Siemsen" <ralphs at blueairnetworks.com> wrote:
> Peter Saint-Andre wrote:
>> JEP-0004 (jabber:x:data) has been updated to incorporate feedback from
>> experience gained while this specification was in Draft status. Once
>> the new Council is installed, version 1.x of this JEP will be voted on
>> for advancement to Final status. If you have comments on the changes,
>> please make them on this list.
> 2.4 - Portability
> XHTML forms are rejected because the lack a <required/> tag. I don't
> follow this reasoning at all - surely if that was the only problem you
> could simply add the tag. I'll have more to say on this at the end.
> No formal mention is made of how <required/> is to be used. Some of the
> examples show it, and I can guess about it, but there definately would
> need to be more detail given. How are clients to respond when they get
> a required field, but they do not understand or implement that
> particular field type? Or is it purely a visual thing, to add a little
> asterisks next to the input widget?
> 3.1 - Field types.
> The given values are rather limited, and they do not form an orthogonal
> set either. For example, no hidden multiline text input (say I wanted
> to paste in my RSA keys). No way to specify suggested field widths for
> graphical browsers. This things could be added by means of <x> tags,
> but that makes it even harder to validate --- the <x> tag is already an
> abomination in this regard.
> A more flexible way for text fields would be to have a base type with
> attributes like "hidden", "width", "height". When height==1 (default)
> then its a single line. Clients can ignore these attributes if they
> wish, and still achieve the required functionality.
> It seems a litte egotistical to include the special-case "jid" field,
> which is highly Jabber-centric, while all the other fields are generic.
> However, it would make a lot of sense to include more specific field
> types, like "integer", "float", "date", "time", "currency value". Then
> GUI clients could render them into something more interesting/useful
> than a bunch of text boxes -- a big selling point for end users.
> Of course, non-GUI clients must not be forgotten, so the "complex"
> field types should be expressed using optional attributes on top of the
> simple base types.
Interesting. I don't know how much extra stuff the client can do to display
fields other than date fields. That is unless we start to allow edit masks.
I think either simpler or going all the way to edit masks would be most
> And no, I don't think using <x> tags all over the place is the answer to
> this problem. Having data types that correspond to real-world needs
> makes life simpler for clients and service providers.
> The JEP needs to recognize that real-world needs drive what actually
> gets deployed. I'll make this point repeatedly: if something is not
> specified in the JEP then ad-hoc implementations will spring up, and
> inevitably this will lead to inoperability between clients. Fragmenting
> an already small market space is clearly a Bad Thing(tm) for Jabber.
Agreed. Perhaps compliance tests (JabberPowered) could help here?
> 3.3 - Errors
> This is actually a much bigger deal in real world scenarios. It is
> critically important to decide the "who, what, when, where" of error
> checking. For the end-user experience, it is important to do as many
> up-front checks as possible (eg. invalid date, string too long, etc.)
> where feedback is immediate. This means that sufficiently rich data
> types must be used (hence my comments in section 3.1)
Agreed. Although without edit masks, your checking is going to be pretty
> 4.5 - Whitespace
> This one bites us because mac, unix, and windows cannot agree on line
> terminators. Behaviour must be rigidly defined, or else you'll get
> double lines, missing lines, and more fun. The "accept liberally"
> policy causes trouble here... does "\r\n" mean one line or two? What
> about "\r\n\r" or "\n\r"? And beware of leading whitespace issues also,
> eg. Example20 shows the data nicely indented, but i'll bet the user
> didn't type it with leading spaces/tabs. So the example is inaccurate.
> I'd suggest ignoring/banning all control characters. Use <br> to mark
> linebreaks. This would mean that client authors cannot just copy the
> string from their input widget over into the jabber packet... is that
> too much to ask? Of course that is exactly why we have a problem in the
> first place...
It is a problem. I think defining a Jabber line terminator and other
whitespace is a nice fix. Then clients simply do their own tracking and
converting of endlines etc to the jabber defined characters. I'm not sure
how fond I am of allowing HTML inside of field values. Everything needs to
be encoded for XML though so I supposed HTML or control characters in the
field won't matter for the server or transport. Only in protecting other
users from attacks... Like pounding someone with ^g bells.
> 4.7 - Labels
> Reading between the lines here, labels are allowed to contain underscore
> "_", presumably to indicate keyboard accelerator shortcuts. This is an
> important feature for end users who use GUIs. As such it really should
> be explicitly documented in the JEP.
> It would be clearer to use an optional "accelerator" attribute, instead
> of piggybacking the underscore inside the label. Then there is no
> guesswork. Furthermore, it allows more creative expression of
> accelerator keys (including shift-, control- and alt-/meta- bindings).
> Yes, this becomes client/platform specific, but at least if we put it in
> the JEP then we've got a _defined_ way to make use of this feature. So
> we might have accel="a" or accel="C-x" etc.
> Also, tabbing order is an often requested feature. Most end-users only
> notice when this feature is absent, or doesn't work the way they would
> expect. Maybe an optional "taborder=N" attribute can be added. Again,
> the JEP should take a stance on this, so as to prevent many incompatible
> implementations from appearing.
Agreed on all points.
> 5.3 - Workflow
> This is perhaps the most important application for all of the complexity
> that x:data is trying to provide. Simple one-page registration forms
> can be handled through the existing namespaces reasonably well. But
> being able to generate forms dynamically, for virtually any client, that
> is a truly useful thing.
> The <thread> tag doesn't really buy much here. It does not record the
> status of a multi-page form, it merely gives all the requests a common
> name. The ID tag in an IQ provides this already. Really you want
> thinks like links to the next/previous stage, cancel, clear, etc.
> I'm not sure that I see the value in using anything but IQ's for this
> sort of transaction. Message and presence tags can be used to initiate
> a transaction, eg. to alert you that there is something to do. The
> message would include a link to the form source - another JID/namespace.
> Similar to the x:oob concept, but link to a jabber entity which handles
> the form generation/submission.
> Think of forms as something like modal dialogs in typical applications.
> They appear in direct response to user action (menu selection,
> hotkey, clicking on a link). The user works their way through, or
> cancels, before returning to the application. It makes no sense to have
> such requests get spooled offline (eg <message>), or even worse, get
> redirected to your pager/cellphone (unless of course it too speaks
> Jabber, in which case the resource priority feature that already exists
> will take care of delivering the event to you).
This would be useful but I'd like to see how it would actually be
> This is a general comment about using the <x> tag to augment the
> existing search and register namespaces. Doing so makes parsing much
> more difficult. It is conceptually incorrect because it mixes new and
> old methods for doing the same thing into the same code base. It would
> be much better to make a clean separation right up front. That way the
> old code can be left alone, and new stuff added alongside (rather than
> So I propose that clients that support x:data actually indicate it when
> they make requests. Instead of doing a query in jabber:iq:register to
> get the paramters, they should first try jabber:iq:xdata:register. If
> that fails they can fallback on the old method. In a few years when
> every client and server supports xdata, the old namespace can be
> retired, and the fallback can then removed.
> Instead of an <x> tag inside the <query>, we can then use something like
> <form>, which better describes the <field> elements within. The form
> tag can have attributes like a name, a unique ID for tracking, and more.
> It can specify an "action" field which will handle the completed form.
> And we can have multiple <forms> in a single request/reply, useful for
> example to represent results of multiple directory searches.
> Finally you might say, there is nothing "x" about this "xdata" model.
> Well that's right, so perhaps instead of xdata we should call it what it
> is: a form. That would give us namespaces like jabber:iq:form:register
> and jabber:iq:form:search, etc.
I like this idea a lot.
> To me, JEP-0004 does not look like a major improvement over the existing
> jabber:iq:register and jabber:iq:search namespaces. It is certainly a
> step in the right direction, but needs at the very least to have some
> room for growth options down the road. Otherwise, in two years time
> when everybody realises they wanted a "date" field type, we'll be forced
> to abandon jabber:x:data and move to a new namespace-du-jour. Or come
> up with another, even more complicated method for being backwards
> It seems that the jabber community is just scratching the surface of the
> forms data issue. Meanwhile, the W3C has been dealing with HTML forms
> for well over a decade. We'd do well to learn from their mistakes
> (starting with <input> tag then later adding different types, then
> eventually coming up all sorts of non-specific "next generation"
> models). I definately think KISS principle should apply, and we can
> safely get rid of a lot of historical cruft - for example we can make
> the "type" attribute mandatory - but the basic ideas learned in HTML
> forms are good starting blocks for the Jabber model.
> Using <x> tags to add the x:data into existing namespaces may seem like
> a good way to introduce the concept right now, but down the road it will
> only be a hindrance to development - old version cannot be retired
> because they are the container for the new. And we can't just "forget"
> the old protocol without breaking the established schema for the older
> namespace. Better to introduce a new namespace now - it is simpler and
> cleaner this way.
>From what I've been seeing, people have been looking short-term to document
and shore up existing protocols. So I'm not sure how much people will like
the idea of completely new protocols. However, you have my vote. :)
> If you've read this far.. thanks for hearing me out,
Thanks for writing. Well thought out commentary.
> PS. I'd be willing to rewrite the JEP (or submit a new one) to reflect
> my idea of how this x:data idea should be done. I really didn't write
> this whole rant^H^H^H^Hessay only to stir up trouble, rather I'd like to
> see a genuinely useful standard emerge.
I think that would be useful. Even if its not merged into the current JEP
it could be used as a new JEP targeted at the JNG whenever that moves from
debate to working status.
More information about the Standards