[Standards-JIG] Re: XHTML-IM: moving forward
stpeter at jabber.org
Mon Sep 13 15:52:43 UTC 2004
In article <opsd4q0vl5qj7son at smtp.chello.nl>,
"Tijl Houtbeckers" <thoutbeckers at splendo.com> wrote:
> On Fri, 10 Sep 2004 15:24:08 -0500, Peter Saint-Andre <stpeter at jabber.org>
> > 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.
> I *do* think the discussion has shown there are legitimate use cases that
> apply to a broad group of users that go beyond the current XHTML-IM spec.
> Particulary in content publishing. Mostly, yes that involves tables. This
> was also the most requested feature before the discussion started, by
> multiple people, and again during the discussion.
> Yet I do think we came to a consencus it's unfair to expect all clients to
> implement it. I think having an XHTML Disco node, where you can disco
> which XHTML "modules" are supported is sufficient for that. I don't think
> these would have to map directly to the actual XHTML spec of such modules,
> rather, there should be a description about them somewhere like in the
> XHTML-IM JEP, telling which elements and properties are recommended and
> which not. I don't know if these would all have to be put in JEPs either,
> you could simply register them with the Jabber Registrar.
> So someone could create a simple-tables module without nesting, and
> someoen could create a superset that has "full" table support, but for
> example I could also have the benifit of finding out whether images are
> supported (If they are not I could send a hyperlink instead). If someone
> wants to do that text-to-speech thing we've talked about, create a module
> describing the needed CSS elements.
> Would this really require such big changes in the JEP? The section on
> disco would grow with the "standard" addition of a disco node for XHTML
> (like with AMP), the Jabber Registar stuff would need some work, and every
> currently described module would have to get a Jabber Registrar registered
> The alternative *is* to use different namespaces for this, I suppose a new
> one for each addition and each combination of additions would be needed
> (and a JEP for all of them too??)? I'm not so convinced of the elegancy of
> this, since it is still in the "territory" of simple XHTML structure/style
> in IM messages. I think "disco" is the best way of provinding such
> extendability, like it's done in AMP.
OK, there are several issues here.
One is doing the right thing as far as the W3C is concerned. Despite the
fact that it took me almost a year to get feedback, the W3C likes the
fact that we've used XHTML Modularization to define an XHTML Integration
Set. They've defined XHTML and have recommended best practices regarding
how to "profile" that technology, which we've used in JEP-0071. So I do
think it would be good for us to continue down that path in any further
profiles of XHTML that we develop. I'm sure that some people in the
Jabber community see this as an unnecessary waste of time and effort
(though perhaps they don't care because it was my time and effort ;-),
but it is the polite thing to do when using someone else's technology.
Therefore I would say that simply having the Jabber Register keep track
of which disco feature (i.e, XHTML-IM "bundle") contains what XHTML
elements and CSS properties will not quite work. This means that we
would still need to go through the work of defining an XHTML Integration
Set or some other XHTML profile that adheres to the XHTML modularization
XHTML modularization also defines certain XHTML modules as core. This is
probably good so that we avoid situations like this:
That is, what do you do if a client returns some weird disco result such
as only supporting the XHTML tables module but nothing else? Such a
result is nonsensical.
So may want to leave the door open to defining additional XHTML
Integration Sets (or XHTML Family Modules, though I would prefer the
former) in the future. Thus we would adjust JEP-0071 to define the
container mechanism as well as the first Integration Set (which we could
label something other than XHTML-IM if desired -- XHTML-IM-Basic or
somesuch might be more descriptive); we could also split the first
Integration Set into a separate JEP and make JEP-0071 just the
framework, but that is more work for the author without a great deal of
benefit as far as I can see. Then others could develop different
Integration Sets as they define requirements for such functionality.
Preferably such Integration Sets would be additive; e.g., the set that
defines the tables support would include everything in XHTML-IM-Basic
plus tables, thus making it easier for implementors. Naturally there is
the potential for overlap and confusion (I want basic + scripts, you
want basic + tables, someone else wants basic + objects, etc.). But
that's why we have an open standards process -- to discuss this stuff
and reach consensus.
More information about the Standards