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

Eve:
Thanks for your input. Some replies in-line.
-Aaron

> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@east.sun.com]
> Sent: Tuesday, October 24, 2000 6:40 AM
> To: Daniel.Veillard@w3.org
> Cc: Cohen, Aaron M; 'Daniel.Veillard@w3.org'; Eve.Maler@east.sun.com;
> 'Lloyd.Rutledge@cwi.nl'; 'thierry michel'; www-smil@w3.org
> Subject: 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.
Yes, this is accurate. At this stage, we do not want to require full
XPointer support in a smil player, in part because of the additional
complexity, and in part because we have not determined what is the meaning
of all possible XPointer expressions, such as what does a range of smil
mean?

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

> However, I'm not crazy about it if the motivation is to save 
> on ad-hoc 
> */xml media type handling in a SMIL implementation.  
I'm not sure what you mean here (what adhoc processing?). SMIL has it's own
mimetype, and that mimetype is bound to the semantics that we are
discussing. It is important that an XML processor _can_ process the smil as
generic xml, but if the result does not conform with the smil specification,
it won't play in a conformant player, although it will still be legal xml.

SMIL players can choose to handle xml media as they do any other media.
Media types are not specifically defined in smil. If a player supported
generic XML as a media type (perhaps with associated CSS/XSL style sheets)
the player would have to support processing that media as general XML,
including the XLink syntax.

We're only talking about XLink syntax as it refers to the smil files here,
not the referred to media.

Or am I missing the point here?

>(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*.  
Yes, okay. I think that this aligns with what I say above.

> 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?...
I hope that this helps some. We are not trying to say anything about how a
smil player handles XML as _media_.
 
>          Eve
> --
> Eve Maler                                          +1 781 442 3190
> Sun Microsystems XML Technology Center    eve.maler @ east.sun.com
> 
>

Received on Tuesday, 24 October 2000 15:02:33 UTC