Re: Fwd: [xml-dev] SMIL markup

On Wed, Aug 20 2003 "Simon St.Laurent" wrote:

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

There is no single SMIL viewer for all things SMIL.  Since SMIL is a
meta-language, only its instance languages, like SMIL Profile, SMIL
Basic, XHTML+SMIL and SVG have players, and these players are (mostly)
separate.

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

How is this distinction typically handled in XML?

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

Again, SMIL *does* support text as element content, just as HTML and
SVG does.  HTML, SVG, and the profiles of SMIL with text content allow
PCDATA content of elements as displayable text content.  Some elements
can also contain style and script code, but their syntax and length
precludes inclusion as an attribute value.

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

XHTML+SMIL provides a means of putting all displayed text in one file.
Of course, non-text(-encoded) media will probably always be external.

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

XHTML+SMIL is readily the most widely supported SMIL format, since it
is supported by Internet Explorer.  However, it is not a
Recommendation (see below).

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

Again, XHTML+SMIL uses HTML and CSS to format the displayable text
that it directly contains as PCDATA element content: all text content,
format and SMIL code in one file.

However, despite all my disagreement with details in your comments,
you are complaining about the right topics (albeit in the wrong way
;).  You're right, SMIL does need more direct containment of formatted
text, along with other structured, formattable media, such as SVG.
I've described the ways SMIL currently supports this.  While
XHTML+SMIL provides direct containment for formatted text, the
format's standardization process has stalled before becoming a
Recommendation.  Thus, if you are interested in actively promoting
text as element content in SMIL, I suggest you campaign for promotion
of XHTML+SMIL (or an equivalent) to Recommendation so that SMIL text
content becomes official.  Work on XHTML+SMIL is currently part of the
charter of the W3C HTML Working Group (see
http://www.w3.org/2002/05/html/charter#deliverables).

The HTML WG is also working on "An XHTML + MathML + SVG Profile"
(http://www.w3.org/TR/XHTMLplusMathMLplusSVG/).  If you really wanted
to push the group (or, even better, join it and "pull" it), promote
inclusion of SMIL elements with the text, graphics can math display
elements.  This would fit quite well with the group's charter.

Take a look at the Timed Text W3C effort as well
(http://www.w3.org/AudioVideo/TT/).  This group is working on,
basically, timed captions and subtitles for inclusion in SMIL
presentation.  Perhaps you could get involved in this group and
promote direct inclusion of such text.

I hope this gives you enough answers (and enough to do ;),
Lloyd

--
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 Monday, 25 August 2003 04:33:00 UTC