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

----- Original Message -----
From: "Eve L. Maler" <eve.maler@east.sun.com>
To: <Daniel.Veillard@w3.org>
Cc: "Cohen, Aaron M" <aaron.m.cohen@intel.com>; <Daniel.Veillard@w3.org>;
<Eve.Maler@east.sun.com>; <Lloyd.Rutledge@cwi.nl>; "'thierry michel'"
<tmichel@w3.org>; <www-smil@w3.org>
Sent: Tuesday, October 24, 2000 3:38 PM
Subject: [Moderator Action] Re: XML Linking WG review of SMIL Last Call
Working Draft


> An interjection, hopefully relevant:
>
> At 10:10 AM 10/24/00 +0200, Daniel Veillard wrote:
> >   I think it all boils down to the following points:
> >    1/ SMIL uses only the bare name part of XPointer.
> >    2/ XML Linking WG until now has rejected any attempt at subclassing
> >       XPointer.
> >    3/ XPointer is the language for the fragment identifier of
> >       text/xml and application/xml resources.
> >    4/ XML 1.0 has the ID/IDREF mechanism when addressing elements within
> >       a single document is needed. There is some expectations that
> >       a#foo will target the ID "foo" in the resource a and this predates
> >       XPointer
> >
> >  I understand the SMIL view point as:
> >    "requiring only bare name support of XPointer is a fair use"
> >
> >and the possibility of evolving toward full support in future revision
once
> >XPointer is fully deployed.
> >  Assuming I understood it properly I will try to discuss this with the
group
> >and get back to you too.
>
> Is the following description correct?  SMIL describes the generating of
> addresses, where the address appears inside a SMIL document and the
> referent appears (where? in the same document or a different one?).  The
> address is in the form of a fragment identifier in a URI reference, and
the
> referent is intended to be a SMIL document.  Because only a subset of
> XPointer fragment identifiers is guaranteed to appear in these addresses,
> SMIL processing does not require an "XPointer processor" to handle the
> addresses, but it could choose to hook up a full XPointer processor if it
> wanted, because the syntax is a strict subset.
>
> If this is an accurate description, I don't have a big problem with the
> part about generating a strict subset; hey, if you want to synthesize or
> generate XPointers in a particular way, that's your business.  (The
> XLink-to-RDF mapping note does something similar, all while assuming a
> */xml media type.)
>
> However, I'm not crazy about it if the motivation is to save on ad-hoc
> */xml media type handling in a SMIL implementation.  (By contrast, the
> XLink-to-RDF motivation is the comparison of addresses.)  If the
referenced
> resource is served/treated as */xml, then you should assume that an
> XPointer processor needs to be hooked up, and you would ideally accept all
> valid XPointers in the places where you currently dictate a limited set of
> them.  If it's served/treated as */{smil stuff}, then you could define a
> subset of XPointer but, in practice, *it would now be its own fragment ID
> language*.  My goal here is to try and keep the media type/fragment ID
> system modular and clean.
>
> So now my question is, What is the real story and what are the
motivations?...
>
>          Eve
> --
> Eve Maler                                          +1 781 442 3190
> Sun Microsystems XML Technology Center    eve.maler @ east.sun.com
>

Received on Wednesday, 25 October 2000 18:13:55 UTC