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

Peter:
Some comments below.
See my previous email for more.
-Aaron

> -----Original Message-----
> From: Peter Stark (ECS) [mailto:Peter.Stark@ecs.ericsson.se]
> Sent: Wednesday, March 14, 2001 12:12 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, 
> 
> I note that the SYMM group has taken a very different 
> approach to conformance and interoperability than, for 
> example, the HTML group.
> 
> Aaron writes:
> > 
> > The most straight forward way to declare that a document can 
> > be played by a
> > smil basic player is:
> > 
> > <smil xmlns="http://www.w3.org/2001/SMIL20/WD/Language" 
> > 	xmlns:basic="http://www.w3.org/2001/SMIL20/WD/HostLanguage" 
> > 	systemRequired="basic">
> > ...
> > </smil>
> > 
> 
> So there is no way for the developer to check whether the 
> document includes only the SMIL Basic modules. There is no 
> DTD/Schema for SMIL Basic, that includes only the basic modules. 
That has not been a requirement up to now. I suppose that we could have a
new attribute "completeRequirements" that would list all modules required
for playing the document, and some user agents could insist on this being
present.

Note that full blown SMIL 2.0 document authors can prevent a document from
being played on a bare bones smil 2.0 player by doing this:
<smil xmlns="http://www.w3.org/2001/SMIL20/WD/Language" 
	xmlns:smil20lang="http://www.w3.org/2001/SMIL20/WD/Language" 
	systemRequired="smil20lang">
...
</smil>

This says that support for the entire smil20lang is required.

Another option that could work for you that we have not discussed is whether
a user agent should _assume_ the above if there is no systemRequired
attribute on the smil element.

> And since the SMIL media type does not indicate what 
> modules/profiles the client supports, the server can do 
> nothing more than serving the same SMIL document to all types 
> of SMIL clients. 
content type negotiation is independent from document format. The smil media
type _does_ indicate what modules are required to play a presentation, but
that in itself does not help you deliver the right document to a specific
player. You need another mechanism (such as CC/PP) for that.

Although now that I think about it, SMIL 2.0 does provide sort of a poor
man's version of this, if you look at customizing a presentation as a
document set instead of as a single document.

This could be done using the systemRequired mechanism in a wrapping control
smil document, with automatic links forwarding to the actual presentation:

<switch xmlns:smil20lang="http://www.w3.org/2001/SMIL20/WD/Language" 
     xmlns:basic="http://www.w3.org/2001/SMIL20/WD/HostLanguage">
	<a systemRequired="smil20lang" actuate="onStart"
href="full-smil20-presentation.smi"/>
	<a systemRequired="basic" actuate="onStart"
href="basic-smil20-presentation.smi"/>
</switch>
 
> I am also worried about the following statement:
> > 
> > We expect that other standards bodies will build profiles 
> > starting with the
> > smil basic scalability framework and the host language 
> > conformance set.
> > These profiles can have their own doctype/namespace/dtd and 
> > make documents
> > written in them directly identifiable as such.
> > 
> 
> If, for example, the WAP Forum or the 3GPP would define their 
> own SMIL profile using only SMIL 2.0 modules, should they 
> also define their own XML namespace? I hope the answer is no.
It depends. Using the scalability framework, they can still use the smil20
and/or smil 20 language namespace. But as I keep saying, you cannot have it
both ways. You cannot use the full namespace, but at the same time use the
XML Schema to restrict the document type for that namespace. Elements in a
namespace using an XML Schema can only have one content module.

I suppose that you can get around this by using a DTD to define your content
model, and use only the elements that you want within the smil 2.0 language
namespace. But as far as I know, the way that schemas work, you need to
define the content module of the elements in that namespace, and so the full
smil 2.0 language and a syntacticly restricted language like you are
proposing cannot share the same namespace and be defined with an XML Schema.
XML Schemas make a association between the "full" name of an element and its
content module. AFAIK, this is how it works, and we have to work within this
framework.

Again, this is not to say that a language profile cannot make additional
non-XML Schema requirements on the user agents or document authoring
guidelines.

I hope that this helps. Ii admit that the namespace thing is pretty hard to
wrap your head around, but I am just using it, I didn't invent it.
-Aaron

> 
> regards,
> 
> Peter 
>

Received on Wednesday, 14 March 2001 12:48:59 UTC