[Standards-JIG] XHTML-IM: moving forward
stpeter at jabber.org
Fri Sep 10 20:24:08 UTC 2004
Now that JEP-0071 has been updated to incorporate the consensus of the
list, it remains to discuss further the suggestion that we make that JEP
more flexible or extensible in some way so that additional profiles of
XHTML over XMPP can be easily defined in the future. The main desire so
far seems to have been to include XHTML tables, but other XHTML profiles
might be desirable in the future as well.
JEP-0071 is structured as an XHTML Integration Set. The W3C (or, more
precisely, the W3C spec "XHTML Modularization") specifies how to
construct XHTML Integration Sets and other kinds of subsets using the
concept of XHTML modules. If folks in the Jabber community want to
define other profiles for sending XHTML over XMPP, they will most
likely want to define such profiles as XHTML Integration Sets since that
is how the W3C prefers things to happen.
As to how we would proceed, it seems to me that there are three options:
1. Define an abstract mechanism for including XHTML content in XMPP,
such that (1) the Integration Set currently defined in JEP-0071 is one
instance of that abstract mechanism and (2) other instances could be
defined in the future. Each instance would be separately discoverable.
2. Once someone has defined a set of requirements for some kind of
rich IM messages (e.g., including tables), we would define a separate
Integration Set with a different wrapper namespace, for which support
could be discovered using the normal methods.
3. Simply use the 'http://www.w3.org/1999/xhtml' namespace in order
to include the full range of XHTML markup if desired, support for
which could be discovered using the normal methods. (But not everyone
wants to include all XHTML, so this is probably too much.)
It's not clear to me what #1 gives us that #2 does not. Some have
suggested that it would be nice to be able to discover exactly which
features or feature bundles (which map to XHTML modules?) another client
supports before starting to send messages with XHTML markup to that
other client. So it would be nice if I could discover that you support
the Basic Tables Module before starting to send you tables.
How granular does this need to be? Can I discover whether you support
the "padding-right" CSS1 property before trying to send you a message
that uses that property? That seems like overkill, but it's not clear to
me where we draw the line in discoverable feature support. Do we limit
it to XHTML modules only? Do we limit it to the XHTML Integration Sets
that are defined in each JEP that profiles XHTML usage in XMPP? So
perhaps I can discover whether your client supports "XHTML-IM-Basic"
(a name for what's in JEP-0071 right now) or "XHTML-IM-Intermediate"
(JEP-0071 + tables, perhaps) or "XHTML-IM-Advanced" (JEP-0071 + tables
+ other goodies). But can't we simply do that via option #2 above
(separate integration sets and wrapper namespaces for each set of
requirements)? What does it buy us to define an abstract mechanism for
writing XHTML integration sets for use in XMPP? Someone needs to make
the argument that the extra effort (abstraction is always work) is
worth the cost. Right now I'm just not seeing it, but perhaps I'm too
close to this after having worked on it for so long. What is the basis
of the argument? Not having to use multiple wrapper namespaces?
As far as I can see, the current JEP-0071 addresses the requirements of
a basic structure-and-styling mechanism for IM messages, which is what
we've wanted all along and which meets the needs of 90%+ of the end
users and developers out there. If the JSF wants to define other
profiles, the requirements and use cases for such functionality would
need to be clearly defined so that we could figure out how to address
those requirements in terms of XHTML modularization. I see no special
reason to design a framework for such work given that (1) it does not
seem to be of general interest and (2) the requirements and use cases
for such work have yet to be clearly defined. In general we prefer not
to design protocols for the sake of some unspecified future. If folks
on this list can argue persuasively that we need a general framework
for multiple XHTML Integration Sets over XMPP, then the Standards JIG
and Jabber Council will of course consider those arguments. Until then,
it seems reasonable to err on the side of simplicity by (1) not defining
such a general framework and (2) proceeding with JEP-0071 as it is.
If no one puts forth such an argument in the next week or so, it seems
that it would be appropriate for the Council to move forward with voting
Jabber Software Foundation
More information about the Standards