Re: Marking up alternative versions of content

On Aug 4, 2007, at 7:21 PM, Sander Tekelenburg wrote:

>
> [I see you already pointed to a couple of things I just posted  
> about. Sorry
> about that. I normally read an entire thread before posting to it.  
> My mistake
> for not doing that this time.]
>
> At 22:06 -0500 UTC, on 2007-08-03, Robert Burns wrote:
>
> [... @type for MIME types, so doesn't allow more generic indication]
>
>> The @type attribute is not always a MIME type. The INPUT and BUTTON
>> elements both have types that are not MIME types, but simple
>> classifications just like this proposal.
>
> That's true, I didn't think of that. However, I must say that as an  
> author I
> find such context-sensitive meanings of attrtibutes confusing. So  
> my initial
> take would be to dismiss using @type for non-MIME types here.

I don't think of it so much as context-sensitive meanings, since all  
of the @type attributes indicate types for that element. Another way  
to think of it is as an element subtype (as some use the term  
"element type" to refer to an element with a particular name that  
represents all possible instances in the universe of that element).  
However, I admit the values accepted by the attribute are element- 
dependent; and that could cause confusion but need not.

> Also, I believe there is a need to provide both advisory MIME types  
> *as well
> as* advisory information about the 'sort' of equivalent. For  
> example, a
> captioned video might in itself be useful to a user, but when it is  
> in a file
> type format that his system can't consume, it is useless.

That is why I think it would be useful to have a different @type  
attribute than MIME type. If we also want MIME type that could be a  
separate @contenttype attribute. MIME types do not provide the  
vocabulary necessary to describe all of the various ways to deliver  
media (unless we employed HTML defined private MIME types). Its also  
possible that the content type headers on a server will not be able  
to provide that information. So I think we should try to find some  
way to express those varied types within HTML.

> So allowing <alt for=idref title="captioned video"
> type="video/ogg"><video></a>, would probably be useful. Both  
> attributes would
> provide complimentary advisary information. Authors could then do:

I imagined something like captioned video could be handled by a  
primarily machine read @type attribute. That way the UA (with OS  
assistance) could filter out all of the equivalents that either the  
user does not want or cannot consume. The remaining equivalents could  
then have their @title attribute provide the advisory information  
necessary for the user to choose among them. A phrase like "captioned  
video" should not be necessary with this approach since that should  
be machine-discoverable by the UA.

> <video id="speech"></video><!-- folowed by any or no content -->
> <alt for="speech" title="captioned video" type="video/ogg"><video></ 
> video></a>
> <alt for="speech" title="captioned video" type="video/ 
> mpeg"><video></video></a>
> <alt for="speech" title="audio only" type="audio/ogg"><audio></ 
> audio></a>
> <alt for="speech" title="audio only" type="audio/mpeg"><audio></ 
> audio></a>
> <alt for="speech" title="transcript" type="text/html">marked up  
> textual
> equivalent</a>
> <alt for="speech" title="transcript" type="text/plain">plain text
> equivalent</a>
>
> Only issue is, what if the UA supports both MPEG and OGG? Answering  
> myself, I
> suppose a UA could be configured to favour one over the other,  
> presenting
> only the favoured file format. Or a UA could present bth options as
> - captioned video [OGG]
> - captioned video [MPEG]
>
> and leave the rest of the work up to the user. Might well be good  
> enough
> formost users.

Yes, I think that's the way to go. Or if the user has expressed a  
preference for OGG over MPEG, the UA could present those choices in a  
natural language manner (supplemented by the value of the @title  
attribute if it is set).

> [...]
>
>> As for distinguishing between different
>> equivalent types, I think a @type attribute would be good (we could
>> also have @contenttype to provide two different ways to classify the
>> element).
>
> FWIW, I think that would add too much to author confusion of when  
> type takes
> what sort of information. I would be OK with using @type for non- 
> MIME types
> if for all cases where it takes MIME types we would replace it with
> @contenttype. But such a big change would probably generate new  
> problems.
> Using @title and @type would appear to be less dramatic.

That's fine with me. I agree that having both @type and @contenttype  
would be too fine-grained. I was just trying to allow for a MIME type  
attribute if that was important to others.

>
> [...]
>
>> I had earlier suggested a LONGDESC element (ALT, EQUIV, FALLBACK or
>> LONGDESC all work for me). At least for a one-to-one relation, to me
>> it makes more sense to use the @lkongdesc attribute from the original
>> element. To go from primary ---URL---> fallback rather than
>> referencing from fallback ---IDREF---> primary.
>
> For a mere "one equivalent only" solution that might indeed work,  
> yes. I
> don't understand how it would work for multiple equivalents thogh:

My thought was to have a fallback container that would hold multiple  
sibling alternate equivalents. Something like:

<img longdesc='theFallbackForThisImage' src='thisImage' >
…
<!-- either in the same document or another document -->
…
<fallback id='theFallbackForThisImage' >
	<alt type='ContentType' subtype='some-subtype-expression'  title='' >
	</alt>
	<alt type='application/xml'  
subtypes='aValueRepresentingAnXMLNamespace andAnother '  title='an  
interactive multi-media application' ></alt>
	<alt type='video/mpeg' subtype='some-subtype-expression-of the- 
codec'  title='a video of someone demonstrating the interactive multi- 
media application' >
		<object data='thisImageVideo' ></object>
	</alt>
	<alt type='ContentType' subtype='some-subtype-expression'  title='' >
		<object data='thisImageVideo' ></object>
	</alt>
</fallback>

Just as an example. Authors could even mix a peer/sibling list of  
alternates with object style hierarchical/ranked alternates.

>
>> Multiple equivalents
>> could be handled by letting ALT have a content model that includes an
>> initial ALT or adding a @longdesc attribute to ALT too.
>
> Sorry, I can't follow. (Perhaps some example mark-up would help me  
> understand
> what you mean.)

	<alt  id='alt1' longdesc='alt2' type='ContentType' subtype='some- 
subtype-expression'  title='' >
	</alt>
…
	<alt id='alt2' longdesc='alt3' type='application/xml'  
subtypes='aValueRepresentingAnXMLNamespace andAnother '  title='an  
interactive multi-media application' ></alt>
…
	<alt id='alt3' longdesc='alt4' type='video/mpeg' subtype='some- 
subtype-expression-of the-codec'  title='a video of someone  
demonstrating the interactive multi-media application' >
		<object data='thisImageVideo' ></object>
	</alt>
…
	<alt id='alt4' type='ContentType' subtype='some-subtype-expression'   
title='' >
		<object data='thisImageVideo' ></object>
	</alt>

Where now the alternates do not have to be in the same place in the  
document. The author still has the option of placing those ALT  
elements in other documents (for optimization/organizing or any other  
reason).

>
> [...]
>
>> However, I think the for=IDREF approach works better for specifying a
>> one-to-many relation between primary and equivalents (without any
>> implicit or intended ranking).
>
> Ah, OK:)

I actually think we have to problems/ use-cases here that we're  
trying to address. They could be addressed with one solution, but I  
tend to favor separate solutions. One is for authors to provide  
fallback content available a the user's discretion, but not part of  
the author's own intended default presentation. There I think an  
element such as FALLBACK would be the best solution. Adding one or  
more ALT elements to the content model of this FALLBACK would make it  
act similar to a SWITCH element in SVG or XForms. User's who could  
not consume the primary content in the document (for whatever reason)  
could potentially have their UA select the only suitable alternative  
automatically or if multiple suitable alternates existed, allow the  
user to select which one (based on the @type values and advisory  
@title values). (NOTE: by using a primary --@lonagdesc='URL'-->  
fallback approach these equivalents do not have to be in the same  
document.)

The other problem is one of associating the primary content in a  
document with the peripheral content on the same page (primarily the  
ASIDE, OBJECT, IMG, CANVAS, AUDIO, VIDEO, FIGURE, TABLE, and maybe  
even list elements) in the document. This includes two sub-problems.  
The ability to actually reference a specific figure for example a  
parenthetical "(see Figure n)" or "see Table n)". It would be good to  
have markup that could express this and later be presented using CSS  
counters and the like.

The other issue is simply associating discussions that relate to  
images to other peripheral parts of the page. In this way an author  
might have one or several paragraphs where the primary discussion is  
about an image or images floated next to these paragraphs. Or even a  
discussion comparing to images. For that I think is would be better  
to introduce a new global attribute such as @illustrated='IDREFS'  
where authors could set this attribute anywhere and it would  
basically refer the user or user agent to other related content. This  
other content could even be textual or in a table or list or ASIDE.  
This is a looser association than either the [primary -- 
@lonagdesc='URL'--> fallback] approach or the "(see Figure n)"  
approach. However, as a global attribute, authors could set it on any  
element including a SPAN wrapping just a sentence or two.


So I see three different issues here:

  • associating non-text media with invisible-by-default fallback  
equivalents
  • explicit in-text cross-referencing of peripheral content (tables,  
figures, asides, images, videos, audios) from the main section/ 
article of a document (or even non-peripheral cross references)
  • explicit though looser association of elements with peripheral  
content

Take care,
Rob

Received on Monday, 6 August 2007 04:26:22 UTC