Re: img issue: should we restrict the URI

>
> I don't think I understand.  IMG, audio, and video, have semantics
> that are more precise and consequent interfaces that are more
> functional than object.  Img and video state that the embedded object
> is visually displayable;  audio and video that the object has a
> temporal aspect.  Or are you saying that the interface to object
> should be extended to cover all semantic possibilities of anything
> that might be embedded?

Yes, would be a better concept, for more complex formats like 
postscript, PDF, flash, SVG, SMIL, XHTML+SMIL, XHTML+MathML+SVG
obviously an author can simpler decide whether the content is
more related to a static image (image element), a text (a potentially
text element), a media with a simple timeline and visual output
including optional audio output (video) or a media with a simple
timeline and audible output including optional video output
(audio element, with optional video this can be useful for example
for some audio/video clips used to promote mainly songs published
on CDs, where the audio contains the main information and the
video is only decorative). Or there could be another element to
pronounce interactive, animated content (SMIL, SVG, flash) and
finally a generic element like object to cover everything else
without a specific named element. This is the way it is done for
mulimedia content in SMIL, all these elements have the same
technical functionality, only the meaning is changing with the
naming. Ok, SMIL and SVG have another method to cover the
problem of not supported formats and switching to alternative
content, but the method as introduced with object works too -
maybe it is in general a good idea to provide an interface to
the user to switch between all available alternatives and an
optional display in an external viewer to provide an optimal
access to the content.
At least I have often the problem, that on real existing 
pages using multimedia now, the content is not accessible,
display is frustrated for several reasons (often including
the incompetence of authors), but could be made accessible
easily with a user interface providing more access to any 
object content without looking all the time into the source
code of such pages to decide, whether the author used 
completely hopeless nonsense or if I still have a change to
make the content somehow accessible. 

For an author the situation gets simpler, if all these multimedia
elements have the same functionality. The author has not to
care about a technical choice and can concentrate on the
meaning of the element for his purpose.
Implementors have just one interface for all multimedia 
object and the display depends mainly on the used format,
not on the element used to embed it.
With an interface users/readers have always the chance
to explore, what alternatives are availalble and can decide
on their own, if they want to try to manage the content maybe
with a more appropriate program, if the current viewer doe
not interprete a format at all.

Received on Friday, 25 January 2008 11:06:58 UTC