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

Peter:
Thanks for the complements, and your patience in reasoning through all this.
Some more in-line.
-Aaron

> -----Original Message-----
> From: Peter Stark (ECS) [mailto:Peter.Stark@ecs.ericsson.se]
> Sent: Friday, March 16, 2001 2:09 AM
> To: '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]
> 
> 
> 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.  
Okay, we are both on the same page here.
 
> 
> 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.
I don't think that we are saying that, and if so, we don't intend it. There
is a difference between "conforming document" and "conforming DTD". We don't
say anything about what a conforming DTD is (or XML Schema for that matter).
We simply provide a DTD and XML Schema that can be used to validate
conforming documents.

Put another way, it is entirely possible for you to create a DTD which
allows a subset of the smil 2.0 language plus namespace qualified
extensions. If a particular document conforms to this DTD of yours, it will
by definition conform to the SMIL 2.0 DTD. No problem here.
 
> 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. 
I don't think that we need to do this, see above. It's not that we resist
doing it, as much as we are not in a position to create "one true SMIL
Basic" for everyone, and it is not necessary that we do. Create your own
smil 2.0 compliant DTD (you have my blessing!).
 
> Having said this, I think SMIL 2.0 is a great technology and 
> that the SYMM group has done a great job creating it.
Thank you. This is important to hear, as we need to keep showing that there
are people waiting for this, and we need to be allowed to finish taking SMIL
through the process.
 
> 
> 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 13:28:15 UTC