[standards-jig] UPDATED: JEP-0004

[Iain Shigeoka]

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?

Agreed.

> 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
useful.

> 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.

Agreed.

> 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
limited.

> 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
standardized.
 
> Namespaces
> 
> 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
> within).
> 
> 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.

> Summary
> 
> 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
> compatible.
> 
> 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.

Agreed.

> 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.

-iain