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 Thursday, 15 March 2001 14:45:23 UTC