Re: Fwd: [xml-dev] SMIL markup

Lloyd.Rutledge@cwi.nl (Lloyd Rutledge) writes:
>The SMIL meta/mother language does allow element text content in its
>member languages, as is reflected in the W3C note XHTML+SMIL, and with
>display of text in SVG, which uses SMIL animation.

Which doesn't help when the target is SMIL in a SMIL viewer, of course.

>However, the real
>issue you raise is that in SMIL, as is typical in
>presentation-oriented XML formats like SMIL, HTML and SVG, the only
>element content is text to be displayed in the rendered presentation
>-- element content is never descriptive.  This provides a distinction
>between text that is to be displayed and text that structures or
>describes what is to be displayed (the markup).  It has the handy
>effect that if you display a presentation-oriented XML file without
>knowing the behavior of its markup, you will at least see the text
>intended for display, in order.

SMIL itself appears not to understand how this distinction is typically
handled in XML.  The distinction rarely takes the form of confining
textual content to attribute values, never mind URIs.

>This is a fundamental approach that is unlikely to change.  Keep in
>mind that the needs of presentation-oriented XML are quite different
>than those of presentation-independed or raw data XML.  This issue of
>element content is just one area in which the two groups of XML'ers
>take different positions.  What's good for presentation-independent
>data-oriented XML is not necessarily good for presentation-oriented
>XML.

I think you're drawing a false distinction between "two groups of
XML'ers".  It doesn't help that every other presentation-oriented XML
format of which I am aware (notably HTML and SVG, which you cite) does
support text as element content rather than confining it to data URLs in
attributes.

>If you want to include text for presentation, as you indicate with the
>example <text src="data:,This+is+a+test" />, there are actually two
>better means in SMIL.  One, which is the one required by the existing
>SMIL Profile (desktop) and Basic (mobile) Recommendations, is to refer
>to an external file containing the text.  

External files turn into an enormous burden as their number increases.
The data URL is pretty plainly an ugly hack, but external files for
every caption is arguably worse.  

>The other means, which is
>supported by XHTML+SMIL, is to include the text directly in the
>elements inherited from HTML, which can in turn be put in SMIL's
>timing elements.  

If XHTML+SMIL was widely supported... 

>Either approach as the advantage over yours that the
>presented text can have markup around it upon which to base the
>rendering (and, through CSS, the style) of the text's presentation.
>Unformatted text in multimedia presentations in cross-platform formats
>can lead to unpredictable, typically ugly results.

I don't believe I was suggesting support for unformatted text.  I was
suggesting support for text formats which might in fact be amenable to
CSS and other formatting processes - please note how well that works in
HTML and SVG, two examples you cited - rather than locked up in
attributes or external files.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org

Received on Saturday, 23 August 2003 08:28:43 UTC