General vs UI comp docs (was Re: Draft minutes of TAG telcon 2005-11-01

Greetings,

I have a comment on the mixedUIXMLNamespace-33 issue.

Note: I'm a CDF WG member, though I'm not speaking for them here.

In the draft minutes, DanC wrote:
> Don't want to set requirements they can't meet, and the general
> problem is too hard to hand to them

One of the things I've discovered during our work over the past year -
though I admit my bias, as I suspected it was the case before we
started - is that a comprehensive UI-centric solution requires solving,
more or less, the general problem.

I think I have a pretty good idea of what a general solution looks like,
and two of the most important components of such a solution - the
dispatching mechanism and the extensibility framework - we will likely
be tackling in earnest (certainly the former, the latter is still under
discussion).  This isn't motivated by any need to produce "the" general
solution (AFAICT), but instead to ensure that what we come up with is
reusable, even in just a UI context.  For example, it would seem remiss
of us to not say anything about what a XHTML+SVG+MathML document means
when we're going to such lengths to prescribe the semantics of an
XHTML+SVG document, most (all?) of which is reusable for MathML.  Doing
that then, requires an extensibility framework which may end up with
UI-specific fallback behaviour, for example default height & width
parameters so that unknown markup can be visually "blocked in" when
encountered.  But those are optional.  Moreover, all content is in some
fashion visually-presentable, so it could very well be that height &
width have value adorning even embedded RDF/XML content!

This note isn't to motivate any specific action on the TAG's part; I'm
personally happy with the decision to defer.  But perhaps it might help
put the UI/non-UI distinction in context once you get around to
reviewing our drafts that cover this stuff.

Cheers,

Mark.

Received on Wednesday, 2 November 2005 18:07:37 UTC