Re: Fwd: [xml-dev] SMIL markup

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.  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.

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.

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.  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.  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.

-Lloyd

On Thu, Aug 14 2003 "Simon St.Laurent" wrote:

> I'm forwarding this primarily as a courtesy, so as not to be speaking
> badly of SMIL behind its creators' backs.  I sincerely hope that markup
> design will get more attention in future versions of SMIL, or at least
> that future integration with SVG and XHTML will reduce the impact of
> these design choices.
> 
> ====== Forwarded Message ======
> Date: 8/14/03 11:18 AM
> Received: 8/14/03 11:20 AM -0400
> From: simonstl@simonstl.com (Simon St.Laurent)
> To: xml-dev@lists.xml.org
> 
> I've talked in the past about how badly various XML formats use markup,
> but until I got up close and personal with SMIL I didn't realize that
> these problems extended to the W3C as well.  Functionally, I'm quite
> happy with SMIL's capabilities, and I'm using it this week on a project
> that uses about 5% of them.  Unfortunately, I'm also working with SMIL
> at the markup level, generating my SMIL with XSLT, and finding some very
> strange choices in the SMIL markup design.  
> 
> There are two main oddities I've noticed so far:
> 
> 1) All elements in SMIL have empty or child element content.  It's not
> just that there's no mixing of elements and text - it's that there's no
> textual content at all!  Everything is done in element structure and
> attributes.
> 
> 2) For a few tasks, SMIL falls back on <param name="name"
> value="value"/> style markup, seeming to forget that XML offers the
> choice of <name>value</name> or even <name value="value"/>.
> 
> Choice (1) is especially complicating should you want to include textual
> content in a SMIL presentation.  Instead of:
> 
> <text>This is a test</text>
> 
> You get to write:
> 
> <text src="data:,This+is+a+test" />
> 
> I'm glad that I'm using XSLT to generate these and can thereby avoid
> URI-encoding everything I write by hand (extension functions considered
> helpful), but this seems like a perverse choice given that they opted to
> use such a text-friendly format in the first place.
> 
> Choice (2), the param elements - which also apply to text! - make me
> roll me eyes. I'm very grateful that I'm working with this in XSLT, not
> DOM or SAX.  One of my text elements currently looks like:
> 
> <text src="data:,This+is+a+test" region="text_region">
>    <param name="hAlign" value="center" />
>    <param name="fontSize" value="+2" />
>    <param name="fontColor value="blue" />
> </text>
> 
> I know people also complain about SVG's use of the style attribute and
> its compound content, but by contrast with this...
> 
> So you have some idea what I'm doing, I'm generating slides from a
> personal format I concocted to support a presentation with minor
> animation and a few sounds.  For the actual presentation (my polemic
> last week at Extreme), I was planning to use SMIL.  The text issue made
> the XSLT complicated enough that I fell back on SVG, which included
> enough of SMIL to do the job.  Recent developments like text-wrapping
> and presentation of foreign (HTML) objects made it seem like a better
> idea, though in the end I kept my text on a separate XHTML script and
> presented only the pictures and sounds on screen.
> 
> Now, I'm using SMIL because of a piece of music I used in the
> presentation (Also Sprach Zarathustra, opening movement), for which I
> can find no public domain recording.  Public domain MIDI is available,
> but MIDI is far better supported in SMIL than SVG.  And so it goes.  At
> least it's not Flash, right?
> 
> -- 
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com -- http://monasticxml.org
> 

--
Lloyd Rutledge  vox: +31 20 592 40 93       fax: +31 20 592 43 12
CWI             net: Lloyd.Rutledge@cwi.nl  Web: http://www.cwi.nl/~lloyd
Post:   PO Box 94079   |  NL-1090 GB Amsterdam  |  The Netherlands
Street: Kruislaan 413  |  NL-1098 SJ Amsterdam  |  The Netherlands

Received on Thursday, 21 August 2003 16:28:43 UTC