W3C home > Mailing lists > Public > www-smil@w3.org > October to December 2000

Re: XML Linking WG review of SMIL Last Call Working Draft

From: Lloyd Rutledge <Lloyd.Rutledge@cwi.nl>
Date: Mon, 23 Oct 2000 18:07:59 +0200
Message-Id: <200010231607.SAA25952@mast.cwi.nl>
To: Daniel.Veillard@w3.org
cc: ph@w3.org, "Cohen, Aaron M" <aaron.m.cohen@intel.com>, "'thierry michel'" <tmichel@w3.org>, www-smil@w3.org, w3c-xml-linking-wg@w3.org

On Sat, Oct 21 2000 Daniel Veillard wrote:

> How can you use XPointer if it's support is not required ?
> XPointer cannot be subclassed. Either you use it or not.
> Saying it's not mandatory doesn't solve the problem at
> all. Will authors be allowed to use it ?
>   - if yes, then please don't subclass it or register a
>     new XPointer scheme (and manage to get the W3C Director
>     to agree this is a good thing)
>   - if no, then the problem is solved

As Aaron and Philipp have said, the SMIL spec states that some
attributes can use name fragment identifiers.  This is a clear
statement that establishes what happens to be a proper, albeit small,
subset of XPointer -- though the spec makes no statement that these
are actually XPointer, or should be treated as such.  These URI's can,
but don't have to be, passed to an XPointer process.  The end result
would be the same.  Any URI attribute conforming to this specification
would parse as XPointer, regardless of whether the document was transmitted
as application/smil, text/xml or application/xml.

A separate issue, but one the XML Linking WG is perhaps also referring
to, is that the spec as it stands also explicitly does not require URI
attributes that are XPointer to be processed in SMIL.  Arguably, this
implicitly allows XPointer in SMIL URI attributes, and allows SMIL
browsers to perform XPointer processing on them.  This, in turn, allows
the same adoption path for SMIL documents and implementations that
they have for media types: no media type is required in SMIL, but
documents can use any media type, and systems can implement any.  The
market and community will decide what media types tend to be used in
SMIL.

As it stands, they can decide in the same manner for XPointer.  And
SMIL constructs exist to adapt XPointer-using components to systems
that don't process XPointer, just as the same constructs adapt
presentations to systems missing required media-processing components.
This allows for a natural progression towards the integration of
XPointer, and all media, into SMIL.

Requiring XPointer implementation for all SMIL URI's would arguably
delay significantly the introduction of SMIL, since full XPointer
implementation is quite a task, and XPointer is not yet a
recommendation.  It would be great for XPointer to be used in SMIL,
but that can happen after XPointer is released and implementations
become available.  Arguably, SMIL should not be held back waiting.

The second alternative you mention would be to not allow authors to
use XPointer ever, or at least until the next SMIL release, and
similarly, to prohibit SMIL systems from processing XPointer.  This is
obviously not desirable, as it would prohibit market-driven XPointer
integration into SMIL.

-Lloyd

--
Lloyd Rutledge  vox: +31 20 592 41 27       fax: +31 20 592 41 99
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, 23 October 2000 12:08:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:23 UTC