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: Cohen, Aaron M <aaron.m.cohen@intel.com>
Date: Mon, 23 Oct 2000 13:19:25 -0700
Message-ID: <D5E932F578EBD111AC3F00A0C96B1E6F0626B281@orsmsx31.jf.intel.com>
To: "'Daniel.Veillard@w3.org'" <Daniel.Veillard@w3.org>, "'Lloyd.Rutledge@cwi.nl'" <Lloyd.Rutledge@cwi.nl>
Cc: "'thierry michel'" <tmichel@w3.org>, www-smil@w3.org
Daniel:
Thanks for the reply. Some answers in-line.

Lloyd:
A bit of work for you below.
-Aaron

> -----Original Message-----
> From: Daniel Veillard [mailto:Daniel.Veillard@w3.org]
> Sent: Saturday, October 21, 2000 12:54 AM
> To: Cohen, Aaron M
> Cc: 'thierry michel'; www-smil@w3.org; 'Lloyd.Rutledge@cwi.nl';
> Daniel.Veillard@w3.org
> Subject: Re: XML Linking WG review of SMIL Last Call Working Draft
> 
> 
> On Fri, Oct 20, 2000 at 11:47:28AM -0700, Cohen, Aaron M wrote:
> > Dan:
> > My comments below are not the official group response. 
> Instead consider them
> > part of the discussion in working out these issues. I'd 
> like to get your
> > feedback before Tuesday's telecon when we discuss the 
> issues as a group.
> > 
> > -Aaron
> > 
> > 
> > > -----Original Message-----
> > > From: thierry michel [mailto:tmichel@w3.org]
> > > Sent: Friday, October 20, 2000 6:22 AM
> > > To: www-smil@w3.org
> > > Cc: Daniel.Veillard@w3.org
> > > Subject: Re: XML Linking WG review of SMIL Last Call Working Draft
> > > 
> > > 
> > > 
> > > ----- Original Message -----
> > > From: "Daniel Veillard" <Daniel.Veillard@w3.org>
> > > To: <www-smil@w3.org>
> > > Cc: <w3c-xml-linking-wg@w3.org>
> > > Sent: Friday, October 20, 2000 10:48 AM
> > > Subject: [Moderator Action] XML Linking WG review of SMIL 
> > > Last Call Working
> > > Draft
> > > 
> > > 
> > > >    The XML Linking WG recently reviewed the Last Call 
> version of the
> > > > SMIL 2.0 specification at 
> > > http://www.w3.org/TR/2000/WD-smil20-20000921/
> > > > (http://www.w3.org/AudioVideo/Group/ version was also checked).
> > > >
> > > >   Due to the size of the specification, only the parts 
> likely to be
> > > related
> > > > to linking were reviewed, more specifically the Linking Module,
> > > > the Language Profile and the Basic Language Profile.
> > > >
> > > >    First we would like to report our appreciation for your 
> > > making the
> > > > namespace declaration required in the Profile. There are, 
> > > however, three
> > > > points which would have to be checked or modified in 
> the process of
> > > > going to Candidate Recommendation and further:
> > > >
> > > >   - 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.
> > > >     It seems that, since this registration is a work in 
> progress, it
> > > >     must be made sure that it has attained a sufficient 
> > > standard level
> > > >     at the IETF before asking for PR.
> > I don't see that our use of fragments is any different from 
> that in SMIL
> > 1.0, and the registration of a mime type was not a 
> requirement for that
> > version of SMIL, so I do not think that this is a 
> reasonable requirement for
> > SMIL 2.0.
> > 
> > Please explain why SMIL 2.0's use of fragment identifiers 
> is different from
> > SMIL 1.0?
> 
>   I think it is because now there is an official definition for the
> Fragment identifier of an XML (text/xml or application/xml) resource.
> Since you are defining a new neaning for and URI Reference in an
> XML based syntax to avoid clashes you will have to deliver 
> the resources
> with a new mime type. 
>   The URI reference resolution is bound to the Mime Type per 
> RFC2396 and
> following IETF specifications.

I still don't understand this, and I wonder if this answer takes into
account Philipp's reply and the fact that SMIL uses it's own mime type
separate from text/xml.

I'll discuss this more with Philipp and the group and get back to you.


> > > >   - The Linking module suffers (as I reported back in 
> March) some
> > > >     namespaces deficiencies:
> > > >       + the namespace must be specified before starting 
> enumerating
> > > >         the linking attributes and elements of SMIL, 
> > > especially since
> > > >         some attribute's names and values conflict with 
> XLink ones.
> > Both SMIL20 as a whole and the linking module have 
> corresponding namespaces
> > to identify the elements and attributes. By virtue of the 
> required default
> > namespace declaration, all of the linking elements are 
> SMIL20 namespace
> > qualified and their attributes are interpreted in the 
> "private attribute"
> > namespace of the SMIL 2.0 elements. So I don't see where 
> there is any
> > possibility of confusion here.
> 
>   Well the document will be available as a a single page. It 
> does define
> linking syntax. Nowhere on that page is the relevant 
> namespace even printed
> not even in the exeamples !
>   The XML Linking WG ask you to show that namespace before 
> starting enumerating
> the elements in this resource. The only namespace reference 
> in the whole module
> is:
>    "These attributes can be applied to linking elements from other
>     namespaces if allowed by the language profile."
> 
>   I.e. reference by negation something as simple as:
> 
>    "These attributes pertains to the SMIL namespace
>     http://www.w3.org/TR/REC-smil but can be applied to linking
>     elements from other namespaces if allowed by the language 
> profile."
> 
>   Would clarify the situation and I think it would be fine.

Okay. I think that we can change the line as you suggest, and also fix the
examples so that the smil20 namespace is made explicit and obvious, as I say
below. Lloyd, can you make these changes?

> > > >       + none of the full formed SMIL examples in that 
> > > chapter includes
> > > >         the SMIL namespace declaration; this is error prone for
> > > >         implementors or authors and is not conformant 
> to the SMIL
> > > >         Language Profile
> > True. Thanks for catching this. We need to fix this. 
> Editors, take note, the
> > smil element in the examples needs the default NS 
> declaration. Especially
> > the linking module.
> 
>    thanks !
> 
> > > >   - The status of the use of XML Base is unclear. As 
> > > explained in the
> > > >     XML Base specification, the deployment strategy for XML 
> > > Base is by
> > > >     reuse in other XML specifications. Though there is a 
> > > reference to
> > > >     it in the Appendix B, it is unclear if it is normative.
> > > >     There is also no reference to it in the Linking module. 
> > > We hope you
> > > >     intent to use XML Base and make it clear in the 
> Linking Module.
> > We do intend to allow/use XBase once it is a Rec. Right now 
> it is in CR. Can
> > we require support for xbase in our CR period when XBase is 
> in CR? The
> > inter-spec dependency rules always confuse me.
> 
>   I think it's fine, we did this for XLink, you can at least exhibit
> a prior case where this was done.
>   Well it's a chicken and egg problem. XML Base goes to PR by 
> showing evidence
> or reuse, adding SMIL to the list is a great addition !
I'm okay with this as long as Philipp doesn't think that we are getting
ourselves in a dependency knot. Phillip, comments?

>   I the meantime I reread the section on the Profile with Nabil on the
> subject. At this level this is clear, but it is not at all 
> referred in the
> Linking module which is where people interested in Linking 
> would look for
> it (like I did during the review, again the size of the spec makes
> difficult to track everything, if the reference is missing from the
> related module, well the confusion grows).
> 
>   Adding a reference to XML Base in the Linking module would 
> probably be
> sufficient (with a link to the related section in the profile and the
> reference entry in appendix B - or D for the Group version).
How about something like: " A profile using this linking module may also
choose to include support for XBase. When XBase support is available, the
alt attribute URI's should be interpreted in the context of the XBase URI. 

Lloyd: can you wordsmith this and add it to the linking module?

>   I hope this clarifies the situation,
> 
>     thanks in advance,
> 
> 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/
> 
Received on Monday, 23 October 2000 16:19:36 UTC

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