Re: ERT XHTML Module for the WAI

> From: William Loughborough: Sunday, November 19, 2000 1:44 PM
> -----
> What must be accomplished insofar as W3C actions to make this
> doable? IOW what is the "watershed" event after which this
> particular enablement becomes functional?

Modularization of XHTML [1] needs to go to recommendation. That does not
stop us from using it now. In my opinion it is a stable specification: it is
already at Candidate Recommandation, and is past calls for implementation
(ended 17th Nov 2000). I expect it to go to PR well before the year is out
(IMO). According to the HTML roadmap, it says PR Nov 2000, Rec TBD, so it
shouldn't be long now.

> What is the probability of browser support - or is that even
> a major factor? If I understand correctly any browser that
> handles HTML X.x and CSSx will qualify?

Yes, there are no compatability issues whatsoever. Any problems that the
actual programming of m12n creates is up to the HTML WG to resolve before
recommandation. As far as I can tell, this is a working specification; there
are already people using it.
Any HTML groking browser that supports XHTML also supports m12n. Note that
additions with certin behavoiurs aren't automatically supported, but it
doesn't hurt to add them if they have a specific function. For example, our
RDF conformance assertions won't be recognized by IE5, but it will be
recognized by any sofware that we write to check conformance, or anyone else
for that matter.
When the SW becomes reality, we wont have these problems: everything should
be self-explanatory.

> Does this mean that we can make an XHTML "template"

It'll be an XHTML module, for use in XHTML Family type documents. In
english? It's either (depending on how you look at it) an accessibility
add-on for XHTML, or a repair patch for the accessibility problems in XHTML.

> that includes the very stuff our guidelines address, i.e. we
> can make the validation of the file depend on certain treatments:
> (alt presence; accompanying style sheet class elucidations;
> indexing ala RDF assertions about conformance levels; various
> structural conventions, etc.

Yes that is exactly the point - we can change the validation requirements
(to a certain extent). What it means is that we can change the specification
(actually the DTD) for XHTML. For example, if we felt that the longdesc
attribute should be required in <img>, that could quite easily be achieved.
We could make an RDF assertion about conformance level a required element in
the head section. There are some things that are impossible: we can't forbid
un-useful alt texts for example, but if we wrote a specification for the
module, we could quite easily require the alt text to make sense! Anything
that is possible to validate on an XML validator, we can add to our module.
We could get rid of all scripts and images if we thought they were causing a
problem (not saying that they are.....)!

I'm not sure what status we have as a W3C WG. There is some abiguity in the
spec about W3C defined modules using the XHTML namespace. This is one for
the administration to sort out, I'll just follow the m12n specification
"verbatim".

> If this is correct then what're the caveats? If something sounds too
> good to be true...

Thee aren't really any caveats.
We have to be careful about using a W3C technology for this becuase we are a
W3C chartered group: in other words we have to get it "right". However, I'm
not sure if this is something that needs to go through W3C process; I
suppose it would have to, otherwise how would we issue it(?), but we don't
have to do anything other than make sure it works properly. If we are
careful about what we are doing, we should/could get the HTML WGs support
behind us - they are very keen to see people using their specifications,
obviously! Of course, the fact that we are doing it to correct the inherent
problems in 1.1 is besides the point: one of the many aims of m12n is (and I
quote):

"[...] to make it economically feasible for content developers to deliver
content on a greater number and diversity of platforms." -
http://www.w3.org/TR/xhtml-modularization/introduction.html#s_intro

So why not? The HTML WG seem to recognize that XHTML 1.1 doesn't suit
everone, and so they issued m12n to enable us to "fix" it.

> Hello! is anybody here?

I am.....

> How about a tool to convert images to SVG?

That's quite a task. Someone working on SVG will attempt it, surely? I'm not
up on Scalable Vector Graphics, but they sound like a good idea from what I
can fathom.

> Or perhaps built-in content negotiation to assure "graceful
> degradations" and "backward compatability".

Built-in content negotiation. Built into where? Is this a UA thing?

Kindest Regards,
Sean B. Palmer
http://xhtml.waptechinfo.com/swr/
http://www.w3.org/WAI/ER/
http://www.w3.org/WAI/GL/
"Perhaps, but let's not get bogged down in semantics."
   - Homer J. Simpson, BABF07.

Received on Sunday, 19 November 2000 09:52:16 UTC