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

Daniel,

The only fragment id defined in SMIL is of the form
#foo, where "foo" is the the value of an "id" 
attribute of an element in a SMIL document - see
http://www.w3.org/TR/smil20/extended-linking.html#SMILLinking-Into

This seems compatible with the use of #foo in
Xpointer,
defined in
http://www.w3.org/TR/xptr#bare-names

(please correct me if I'm wrong here, so we can
look at fixing this in SMIL, if necessary)

Thus, all fragment id's contained in SMIL documents
are actually XPointers. Of course, not all forms
of XPointers can be used in SMIL documents.

You seem to be arguing that text/xml can only be
used for documents that can potentially use all
forms of XPointers. I would claim that text/xml
can also be used for documents that use only
certain XPointers, such as SMIL or SVG, and don't
see a reason to forbid this. Could you explain 
what could go wrong, giving a concrete example ?

Note that excluding the use of text/xml for these
type of documents would imply that they are somehow
not "real XML", which could be a bit disturbing.
Also, there seems to be no mention of the 
requirement to fully support XPointer in the 
current draft for registering text/xml
http://search.ietf.org/internet-drafts/draft-murata-xml-09.txt

-Philipp

--- Daniel Veillard <Daniel.Veillard@w3.org> wrote:
> On Fri, Oct 20, 2000 at 05:20:15PM -0700, Philipp
> Hoschka wrote:
> > ...
> > > > >   - SMIL is not requiring XPointer and is
> making
> > > heavy use 
> > > > of fragment
> > > > >     identifiers in URI References to parts
> of
> > > SMIL documents.
> > > > >     Hence it must register its own MimeType
> and
> > > not be delivered
> > > > >     as text/xml nor application/xml.
> > 
> > I don't quite understand this. You seem to be
> saying
> > that it would be wrong to send SMIL documents as
> > text/xml and/or application/xml, because SMIL does
> > not fully use XPointer. This probably also means
> that
> 
>   Either SMIL uses XPointer or not. I don't see how
> an intermediate path could be followed safely except
> by
> registering a specific XPointer scheme for SMIL.
>   If you author a SMIL document and use URI
> Reference
> the semantic of the fragment has to be defined at
> authoring time. If you don't use XPointer then you
> should use a specific mime-type to be sure that it
> won't be passed to the XPointer computing engine and
> possibly leading to a different result than
> expected.
>   
> > it would be wrong to send SVG documents as
> text/xml;
> > since SVG also does not use full XPointer.
> 
>   Well maybe SVG made the same mistake, the question
> was asked and answered, one cannot subset XPointer
> 
> 
>
http://www.w3.org/XML/Group/1999/07/LinkingIssueList.html#XP42
> 
>  We actually reopened the issue of providing an
> intermediate
> level of an intermediate level of conformance this
> week
> 
> 
>
http://lists.w3.org/Archives/Member/w3c-xml-linking-wg/2000Oct/0021.html
> 
>  and a very clear majority preferred staying with
> the status quo.
> 
> XPointer has an inherent extensibility mechanism
> based on registration
> of new schemes, currently this is disallowed because
> W3C don't want
> to maintain a registry of xPointer schemes and the
> WG was asked
> to close this feature.
> 
> > I think this is too limiting - there may be cases,
> 
>   I think the limiting factor is that we don't have
> the possbility
> of defining new schemes for smil or svg ! In that
> case the behaviour
> of the handling of the resource assuming it is
> delivered with
> an XML mime type would be well defined. And
> 
>   #smil(foo)xpointer(bar)
> 
>  fragment identifiers could be defined to cover the
> cases where
> habdling the document as pure SMIL or pure XML would
> need different
> expressions.
>  
> > when using a generic XML tool (editor etc.) where
> > it may make sense to send SMIL and SVG documents
> using
> > the text/xml or application/xml MIME type, since
> the
> > document is treated as generic XML, and the fact
> that
> > it is SMIL is immaterial. I don't see the reason
> > to forbid this because SVG and SMIL are not using
> > Xpointer fully - could you explain what would
> break ?
> 
> 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
> 
> > Having said that, SMIL has been using its own MIME
> > type since version 1.0 (application/smil), and
> there
> > is no intention that SMIL clients will play
> documents
> > that are marked as text/xml.
> 
>   Yes but one need to make sure the registration is
> proper,
> since you're currently defining your own
> interpretation of
> the fragment identifier.
> 
> Daniel
> 
> -- 
> Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes  |
> libxml Gnome XML toolkit
> Tel : +33 476 615 257  | 655, avenue de l'Europe |
> http://xmlsoft.org/
> Fax : +33 476 615 207  | 38330 Montbonnot FRANCE |
> Rpmfind search site
>  http://www.w3.org/People/all#veillard%40w3.org  |
> http://rpmfind.net/
> 
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Received on Saturday, 21 October 2000 18:45:12 UTC