Re: XHTML 2.0 Architectural/Accessibility Issues

> a,b,c and d infer a choice class of information.

I wonder if the letters that correspond to each choice can be
considered style or structure? I think that the CSS group considered
them to be style, and styling bullet points is a matter for CSS, but
note also the fact that user agents should copy out the points
(whatever style they may be) into the clipboard.

The thing to aim for w.r.t. XHTML 2.0 - and indeed all those languages
that are under the XAG domain - is that they promote grouping and
selection by elem/attr type, and have sufficient identity that one may
apply a particular style to the elems/attrs later on.

The kind of issue that I was raising was as to why we should have a
seperate element for list items? Why can't paragraphs be list items?
When you think about it, the different types of
grouping/selection/division elements in XHTML are fairly arbitrary,
and their choices seem to be based on those of information types in
pre-Web printed media. I can't say that I'd do it *much* differently,
but I wonder why we should step when we can take a leap.

[...]
> > [Annotations] It means making it as standard as rel="stylesheet"
> > is now; which is probably a good thing.
> >
> > Annotation can also help when adding metadata about the
> > varieties of content of different modalities,
>
> That worries me. the link, rel="stylesheet" is reputedly something
> James Clark threw together to fill a gap.

Oops, I should have been more careful with my wording... I didn't mean
that there should be a mechanism similar to rel="stylesheet"
technology-wise (I'm neutral as to how the link type gets
implemented), I just meant that there should be a very basic type in
the language that everyone can recognize as the de_facto for making
that association. In XHTML, at the moment, there isn't one, and that's
bad news all around.

> > The media type might be MP3, RAM, or even an HTML
> > transcript. The reference to "one minute into the audio"
> > should be the same across content types.
>
> Nice one. xpointer for smil?
> Are you looking for common syntax here Sean?

I'm not actually sure. The general opinion on the semantics of
fragment identifiers seems to change wildy depending upon who you're
discussing it with. TimBL talks about documents as having layers of
genericity:-

   http://www.w3.org/DesignIssues/Generic

And DanC has talked about FragIDs being the same across media types,
but I'm not all that sure that an ID served out in HTML content can
also be served out in RDF as a variant. Are they mutually exclusive?
The RDF MIME type hasn't even been registered, so it's difficult to
tell.

So, what I really want is consensus on the matter. A common syntax
*would* be a very nice thing to have, to avoid things like XPointer.
XPointer was the thing that brought this issue up, for me. [I know
you've already got the following, but I want to spell it out for
reference purposes, and to clarify the position to myself.] Consider
if you have an audio transcript being served up as a variant of some
audio piece. In other words, when you visit:-

   http://example.org/myAudio

Depending upon your "accept" headers, you will either get back an XML
transcript of the audio, or the audio as some other form. Now, it is
quite possible to use an XPointer to point to some part of the
transcript, for example:-

   http://example.org/myAudio#xpointer(id("blargh")

But that XPointer may (and probably will not) apply to the audio media
type, so it's a dodgy URI-reference.

Consistent fragment syntax? I'd settle for almost anything, it'd be
better than what we have now. We already have the ID datatype for XML,
so why not get that consistently deployed? Of couse, when you get to
XML, the meaning of the FragID should probably be cast off to the
schema for the root namespace.

> > * Classes, IDs, extensions. Extra semantics: action item,
> > poem
[...]
> surely the real problem is semantic interpretation of the contents
> of the class attribute.

Yep. More a case of me rambling off in an odd direction, rather than
deliberately changing the problem domain. Identifying the lcasses is
of course important, which is why they should map to URIs, or have
some kind of well-set-out structure so that we can model them. At the
moment, XHTML doesn't really have anything suitable enough, unless you
take the profile attribute to create a kind of namespace for the class
attribute values as well as the rel/rev attribute values. That's a
gross hack, so something needs to be resolved for XHTML 2.0; although
any leaning towards QNames/URIs would make it more difficult to style
with CSS. I've done a fair amount of practical experimentation on this
issue.

--
Kindest Regards,
Sean B. Palmer
@prefix : <http://purl.org/net/swn#> .
:Sean :homepage <http://purl.org/net/sbp/> .

Received on Monday, 7 January 2002 18:27:34 UTC