[Standards-JIG] Re: XHTML-IM: moving forward
thoutbeckers at splendo.com
Mon Sep 13 22:22:16 UTC 2004
Thanks for taking the time to address this,
On Mon, 13 Sep 2004 09:52:43 -0600, Peter Saint-Andre <stpeter at jabber.org>
> 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
> conformance terms:
Hmm.. so it seems we're dealing with a conflict between the way
extendibility works for XHTML and how it works for Jabber. XHTML requires
a new "set" for each combination of supported technologies, while with
Jabber you can easily make any combination you want.
> XHTML modularization also defines certain XHTML modules as core. This is
> probably good so that we avoid situations like this:
> <iq type='result'>
> <query xmlns='http://jabber.org/protocol/disco#info'>
> <feature var='http://jabber.org/protocol/xhtml-im#tables'/>
> 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.
Well that could easily be fixed by requiring core (or even implying it in
all situation, without having to discover it), but we're still stuck with
the problem outlined above.
> 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.
Well, I don't have much of a problem with defining new Intergration Sets
for every new combination (that is actually used), even overlapping ones.
Yes it's a lot of work, but if that's the proper use of XHTML technology
and there's no way around it we should do it that way. If you store the
information about the different "bundles" properly, it's easy to piece
together a new one.
The problem arises with how clients must deal with "new" Intergration Sets
that came out after they were build. I suppose the right approach would be
to just try and render everything from every namespace as long as it's
within an <xhtml/> tag.
But a namespace you don't know still doesn't tell you what features are
supported, so when you find out the namespace supported by a client and
it's one you don't know, you also don't know which "bundles" are
supported. A solution for that would be to still have these "bundles"
registered with the Jabber Registrar (I don't think it's needed to keep a
list there of which elements and css styles are supported, just a link to
a JEP or document that does), so you can still disco to find which modules
are supported in that specific namespace. Another way could be to put the
names of those "bundles" into the namespace of the Intergration Set
somehow, but that sounds a bit hackish.
More information about the Standards