RE: [Fwd: SMIL 2.0 comment: 14.3.2 Conformance of SMIL 2.0 Basic Documents]

Aaron, 

Thanks for your patience. I think now I understand what the underlying problem is. So we can stop this thread. 

There are two use cases: 
(a) broadcasting ("push") SMIL documents to many clients, and 
(b) a client gets ("pulls") a SMIL document from a server. 
I think both use cases are important. 

The scalability framework in section 14.4 makes sense when you want to do (a): send the same SMIL document to many different types of clients, each client plays as much as it can after having looked at the 'systemRequired' attribute. 

I have based my argumentation on use case (b). In this case, I want authors to write SMIL documents optimized for SMIL Basic clients, and HTTP or CC/PP should be used to make sure clients get only the optimized documents (so they don't have to pay for things they cannot play anyway). For this I need a way to identify the language profile (Basic vs. full SMIL 2.0) and a way to check that a document belongs to a certain profile. This can not be done with a namespace declaration inside the document.  


So back to my original comment, section 14.3.2 specifies that "a SMIL Basic document is a 'conforming' SMIL Basic document if it is a conforming SMIL 2.0 document" and a conforming SMIL 2.0 document must, according to section 13.3.2, conform to the SMIL 2.0 DTD. This makes it impossible for me to build a SMIL Basic DTD and write documents that conforms to that, and only that DTD, and still be conforming SMIL documents. So I can not solve use case (b) and conform to the SMIL specification.

This can be fixed if you create a DTD for SMIL Basic to which SMIL Basic doument must conform, instead of the full SMIL 2.0 DTD. The same namespace can be in many different schemas. 

Having said this, I think SMIL 2.0 is a great technology and that the SYMM group has done a great job creating it.


Thanks,

Peter


> -----Original Message-----
> From: Cohen, Aaron M [mailto:aaron.m.cohen@intel.com]
> Sent: den 15 mars 2001 20:44
> To: 'Peter Stark (ECS)'; Cohen, Aaron M; www-smil@w3.org; 
> 'symm@w3.org'
> Subject: RE: [Fwd: SMIL 2.0 comment: 14.3.2 Conformance of SMIL 2.0
> Basic Documents]
> 
> 
> Peter:
> Some replies in line.
> -Aaron
> 
> > -----Original Message-----
> > From: Peter Stark (ECS) [mailto:Peter.Stark@ecs.ericsson.se]
> > Sent: Thursday, March 15, 2001 5:39 AM
> > To: 'Cohen, Aaron M'; www-smil@w3.org
> > Subject: RE: [Fwd: SMIL 2.0 comment: 14.3.2 Conformance of SMIL 2.0
> > Basic Documents]
> > 
> > 
> > Hi Aaron, 
> > 
> > Thanks for the answers. I have a few more questions. See below.
> > 
> > Peter writes:
> > > > 
> > > > * As a content author, I would like to write one SMIL 
> > > > presentation for advanced players and another for basic 
> > > > players (A common use case, I think). How can I make sure 
> > > > that my document only contains the basic modules?
> > 
> > Aaron writes:
> > > You only have to write one smil file. You can use the 
> test attribute
> > > 'systemRequired' to ensure that the SMIL Basic player doesn't 
> > > have to look
> > > at anything that it doesn't know about. You just wrap non 
> > > SMIL Basic block
> > > with systemRequired=<non-smil-basic-module-ns-prefix> and 
> > you're set.
> > >
> > 
> > No. I WANT to write one presentation for the Basic player and 
> > another for the advanced player. The two presentations may be 
> > presented on very different types of devices. As a content 
> > author, I want to make sure the SMIL basic document only 
> > contains Basic modules. If there had been a DTD/Schema for 
> > Basic, it would have been very easy to check.  
> > (Web developers today typically create one version of their 
> > site for mobile phones and another for regular desktops. )
> 
> 
> Okay, well that is what your authors want. Other people want 
> it the other
> way. Go figure.
> Also, the way that you say is currently typical may be due to 
> the fact that
> the authors don't have a choice (yet).
> 
> > [snip]
> > 
> > Peter writes:
> > > > * How can, for example, a mobile phone indicate to the server 
> > > > that it supports only SMIL Basic modules, 
> > 
> > Aaron writes:
> > >
> > > This is a CC/PP thing, and orthogonal to SMIL
> > >
> > 
> > Ok. So you rely on CC/PP for this, and the HTTP Accept header 
> > cannot be used. With CC/PP the content developer has plenty 
> > of information about the client's capabilities, but I think 
> > content negotiation should work also with HTTP. 
> See my upper level smil auto link forwarding example.
> 
> > Working on the XHTML MIME media type, we have been 
> > considering a parameter that is used to identify the profile. 
> > The name of the parameter is still under discussion 
> > ("profile" or "schema-location") but in order to identify 
> > XHTML Basic, the media type will look something like this:
> > 
> > application/html+xml, 
> > schema-location="http://www.w3.org/TR/xhtml-basic"
> SMIL 2.0 defines the overall profile with the default xmlns 
> attribute, and
> further revisions/restrictions with the systemRequired test attribute.
> 
> You can use the XML schemaLocation attribute to point to a schema to
> validate the document, and it that way you could restrict the 
> syntax, but
> note that your schema document will have to describe elements (the
> targetNamespace of the schema) in the smil20/Language namespace.
> 
> 
> > Would it not be possible to do something similar for SMIL Basic?
> You can do this. We have decided not to define a single limited syntax
> version of SMIL Basic ourselves because there is no one 
> correct limited
> syntax that works for everyone. That was the impetus for the 
> creation of the
> SMIL Basic scalability framework.
> 
> > [snip]
> >  
> > Peter writes:
> > > > * If an external organisation, for example WAP Forum, use 
> > > > SMIL 2.0 and use their own namespace, as you suggest below 
> > > > that they can, then what happens when the document is sent to 
> > > > a SMIL player that does not recognize the 
> > > > organisation-specific namespace? 
> > 
> > Aaron writes:
> > > It would not play the document, since elements in distinct 
> > > namespaces are by
> > > default distinct. However, it would not be very much coding 
> > > work for such a
> > > player to recognize such document types, since it would be 
> > > just accepting
> > > essentially the same elements from an alternative namespace. 
> > 
> > So we may end up with the name "smil" in many different 
> > namespaces: a WAP Forum "smil", a 3GPP "smil", and so on. 
> > That would be very bad! 
> True, although as mentioned about, the elements could be the 
> same and use
> the same namespace, just validate the syntax with different schemas in
> different schema locations. You must understand that then you 
> are requiring
> the user agent to process the document against the stated 
> schema, and follow
> the rules for schema processing and error handling.
> 
> > An element name should be in no more 
> > than one namespace. Are you expecting that if an organisation 
> > or company define their own SMIL profile with a new 
> > namespace, that existing SMIL players will support the new 
> > names of the elements?
> If it is popular enough. But the point is that we are not 
> setting a "one
> size fits all policy" because that results in no one being 
> happy. We have
> set the syntax, semantics, and scalability framework, you 
> should apply those
> to your environment as you need to. To me, it sounds that 
> using the SMIL20
> namespace with a different schemaLocation for checking syntax 
> makes the most
> sense to me. However, I wonder what the schema and xml 
> namespace pundits
> will say about 2 different schemas defining the elements in the same
> namespace. It doesn't bother me personally, you can already 
> do exactly this
> with different DTD's defining different syntaxes with different DTD
> declarations.
> 
> > 
> > 
> > Peter
> > 
> > 
>

Received on Friday, 16 March 2001 05:08:20 UTC