[standards-jig] UPDATED: JEP-0004
ralphs at blueairnetworks.com
Mon Sep 23 19:49:23 UTC 2002
Ryan Eatmon wrote:
> This has taken a little bit of time to reply to since it's so large a
No problem.. appreciate your feedback. In particular the clarifications
on the intention for x:data. Probably the introductory section of the
JEP should make this a bit more clear. It seems that the JEP is a bit
like SOAP encoding, as opposed to forms. Including that analogy might
help explain it to others (or a better one!)
> Why would the asker care how big the box should be? That's up to the
> Client to decide. You're asking for hints that would only apply in
> certain situations. And in those, you could pick whatever you wanted
So every client will have different defaults, and forms will vary widely
in apprearance as a result? That doesn't make for a very positive user
experience -- not to mention that the documentation will probably not
match what users see on their screens...
> I can see your stance, but would like to point out that this is a Jabber
> only spec. We are not trying to push x:data into anywhere else. So to
> have a JID only type makes sense for us. It's tied to the protocol, and
> is useful beyond just the form. It's useful for identifying
> programatically what field types are available in the reported side of
You do want to use x:data to represent all sorts of data within jabber,
right? For example as a building block for a better form-handling
model, if I understand you correctly. So i'll continue to argue for
stronger base types. I eagerly await the Validation JEP and other
applications of x:data, so I can see how you mean to use it...
> Um... first off who cares about visually annoying. It's XML. It's ugly
Sorry, s/visually annoying/wasteful of resources/, better? Bandwidth
for transmission, CPU and RAM while processing these elements, and disk
space when spooling offline messages and in log files... I realize
there are other offenders but they're already established, so I am
picking on the new stuff to try and avoid further "wastage"...
> It also locks the render into a single path. Display the options in the
> order I gave them to you. You can't alphabetize a list and do this.
> Because the list order changes. Plus, you can't represent the data in a
> result if you have taken away the vale fields.
Sure you can. The protocol favours you keeping things in the order they
were given, I consider that a good thing. The server knows best, let it
inform the clients. Put the decision making in one central spot.
However there is nothing to stop a client from displaying in a different
order - all that they must do is keep the ID for each item in that case.
I honestly can't see any realistic needs for this, but if somebody
wants it, it is possible.
> Not to mention that converting the return value to numbers doesn't stop
> someone from processing a form incorrectly. It could be text, or
> numbers. If the processor will be hosed by bad data, it doesn't matter
> what form it takes.
True, it does not eliminate the problem, but it does significantly
simplify the processing on both ends, in the vast majority of cases.
Which translates to many fewer ways of screwing up, which is good IMHO..
> You just broke all XPath parsers that want to treat fields the same.
> You can no longer just reach into a field and say XPath("field/value")
> and get back all of the values for the field. Just to save you from
> having to look at a <value/> tag. XML is designed to be structured, and
> often times structure interferes with ease of readability, but it sure
> lets the computer rip through things since it is orderly.
Hmm, now _that_ is a better argument :) Guess I have to ask how widely
XPath is used in the jabber community... in the work i've done so far,
it hasn't been worthwhile at all - forms processing has been pretty
straightforward and I can reach in and get the stuff I need directly,
without needing the power of XPath. Would like to hear others'
experiences in this matter...
> This isn't about rendering... Nothing in the JEP is about rendering.
> It's about representing data. You specify which fields will be returned
> in a result, and what label they will have. That's all.
I think you missed my point - that there should be no distinction
between the initial form "query" (where you get the form elements and
display them) versus the display of "results" after the form is
processed. It should all be part of the same process, no separate
"results" phase at all. As an added bonus of this similification, you
get the ability to do multi-page forms almost for free.
> You're assuming that my client wants to take the data results and put
> them into a table. The data result set is all about representing the
> data as is. Not filtering it for your benefit. if a client wants to
> put the results into a table and sort by a field... so be it. That's
> for the Client to decide. My client wants to build it like a tree.
Sure, that is just like the issue of client re-ordering the choices in a
multi-select field. The protocol should implicitly define an order,
clients can elect to do it differently if they want to... Similarly you
can reinterpret the results and display them as a tree if you like...
However, if a tree is a better way to display the information, everyone
will benefit if you changed the server to respond with a tree instead of
a table... if a client can't do a tree then they just render the text
as a numbered list, for example.
In general I agree with you, data should be separated from its
presentation. However, leaving the presentation up to the clients alone
leads to difficulties for interoperability and consistency. In my
opinion, the only way to make everyone happy is to set out a useful set
of primitive datatypes that all clients must handle, along with a
flexible extension mechanism to allow GUIs to do nicer things.
> I agree. The problem is that the can of worms is already opened.
> Jabber has supported this in the protocol from the beginning. It's a
> little too late to say not to do it. We have to fit the tool to the
> problem, not rewrite the problem because we don't like the tool looks.
Another reason to change namespaces... the existing ones can continue to
work as they did... new ones avoid this problem.
> That said, it is agreed amongst the authors that whitespace is still an
> issue, and one that we are actively seeking an answer too (we have a few
> ideas, just trying to find the one that makes the most sense for now and
> the future).
I honestly thing you have to solve the problem at the source... clients
sending raw data from their GUI's input widget set. Or whatever form
they use to get user input. Clients _have_ to validate it, much as they
must scan for and replace < to < for example.
> Build the tab order in based on the order of fields. Massage the label
> name to be what you want for your specific application.
That turns out to be sub-optimal in many cases. Take a lesson from the
HTML guys on this one ;) Tab order must be explicit, supplied by the
author of the form. I've seen too many users enraged over the "broken"
tab order of some form under their favourite browser.
> This JEP is not about rendering, and never should be. If Joe Bob
> decides that he wants to add a new feature to his OS some day, am I
> going to retro fit the JEP to match it? No. There are lots of GUI
> tools that don't do keyboard accelerators.
And there is an an equally larger number of users who shun these tools,
but will happily use a proprietary product only because it has
accelerators, emoticons and cute sounds effects. Much as I hate the
crap, users do like/want/demand these things. If not in this JEP then
somewhere we need to consider these issues.
> This has been suggested before, and the best solution is to create a new
> namespace tool for providig the needed context. It's not really
> something that needs to go into x:data. x:data is about a single form.
> If your application will require multiple forms, then add a layer and
> use x:data for each of those forms. Don't try and make x:data into a
> swiss army knife.
Fair enough... I was initially under the understanding that x:data was
meant to be this swiss army knife... you've cleared me up on that.
> I can see the usefulness of stating that you support x:data in the
> request, but creating a jabber:iq:x:data:register is ugly, and
> completely unneeded. The jabber:iq:register provides enough context on
> what the form is.
Hmm, is there an unwritten rule somewhere that says that namespaces must
have exactly two colons in them? I don't see how this is ugly, at
least, nowhere near as ugly as all those <value> tags...! :P
> Why can't we simply add a type='date'? Why does it have to be the end
> of the world?
Fine! So long as that doesn't break the DTD, and what about the client
from last week that doesnt' know about this field type? How do we
handle fallback options? (And don't say that's a versioning issue to be
covered in another JEP!!!)
More information about the Standards