Re: [Wikivideo-l] Strange use of SMIL 3.0 in Wikimedia video sequencer ?

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: [Wikivideo-l] Strange use of SMIL 3.0 in Wikimedia video sequencer ?

Daniel Weck
Hi Michael, thank you for your prompt response.
(CC'ed to the public SMIL mailing-list, so that the experts can  
provide feedback too)

Point taken about jQuery generating the "wrong" namespace. Easy to fix  

Globally, I think your approach is very good: SMIL looks like a  
perfect fit for composing the multimedia presentation resulting from  
the video editing process.

Using "native" XML attributes on your media objects (ref) instead of  
param (name/value pairs) would make it easier to validate content  
based on your domain-specific schema, but in practice it may result in  
your EDL content being rejected by some existing (and confused) SMIL  
user agents. I don't know, I've never tried this. :)

I would suggest that at the early stages of development, you make your  
EDL format valid against the DTD of the SMIL 3.0 Language Profile [1]
[2]. You will ultimately adopt only a minute portion of SMIL, probably  
smaller that the Tiny Profile [3] ! Heck, you might even only need  
features from SMIL 2.0 ! :)

I would suggest being consistent when injecting your domain-specific  

* use param name/value
* use namespace-prefixed attributes (or even elements)

I suggest ignoring the Scalability Framework for now. Instead, focus  
on separating pure SMIL constructs versus your specific markup. Once  
your requirements stabilize (i.e. your extensions to SMIL are well-
defined), you may consider ensuring compliance with the SMIL  
extensibility guidelines.

Some of your domain-specific markup strikes me as metadata rather than  
instructions to the media object renderer. I suggest you consider  
adding inline meta [4] to your refs, instead of using param.

There's an open-source project called LimSee3 [5], which deals with  
SMIL document templates. I'm not sure how useful this can be to  
you...just thinking aloud here. They have clearly been facing similar  
issues to yours though.

I hope this helps.






On 4 Oct 2010, at 21:46, Michael Dale wrote:

> Hi Daneil,
> Thanks for your interest in the project. To be sure there is a good  
> amount of work to be done for compatibility with any SMIL like  
> profile or alternate players. Suggestions and bugs that get us going  
> in that direction are good. But it should be noted that it was not a  
> target design consideration for the initial version, rather the  
> format was initially just 'smil like' and loosely defined by the  
> 'player plays' what the 'sequencer outputs'. This is of course not  
> ideal, but is the fastest way to move forward without spending too  
> much time on 'full spec compliance' at the initial stage of  
> development
> As the project envolves it would be ideal to become more smil like  
> so other editors can edit and other players can play and they all  
> work together in a relatively predictable way.
> On 10/04/2010 02:14 AM, Daniel Weck wrote:
>> For example, the format overrides the normal SMIL namespace for "img"
>> and "ref" with xmlns="", although I'm a
>> bit confused as I can't see any XHTML constructs there.
> I believe this is a consiquence of manipulating the XML in jQuery. I  
> never explicitly added the alternate xmlns it just showed up when  
> using the transforms functions. Probably have to expliclty state the  
> SMIL xmlns for jQuery not to assume its xhtml. ( should be easy to  
> fix )
>> There's a
>> combination of XML attribute name/value pairs coming from SMIL a well
>> as from some domain-specific markup (none of which seem to belong to
>> the specified namespace). The format also injects arbitrary  
>> parameters
>> into media objects using nested "param" tags (and  "name" + "value"
>> pairs), thereby adding another layer of extensibility (why mix native
>> attributes and the param element ?).
> I agree its a bit confusing. In some cases like apiTitleKey 'param'  
> it does not have any direct effect on the presentation of the asset.  
> Its only there to help provide a link-back to the asset page in the  
> sequencer and help the sequencer find the asset it it gets moved in  
> the medaiWiki system. If you have suggestions on how to better  
> represent that info I would be interested in hearing that.
>> I am wondering whether there is scope in this "lab" project to  
>> discuss
>> the EDL syntax ?
> Sure :)
>> It would be great if the final format was compatible
>> with SMIL user agents (playback engines and production tools). I am
>> sure that simple changes could be made to "clean-up" the namespaces
>> and to define an XML schema that draws the boundaries between SMIL  
>> and
>> domain-specific markup.
> Sounds good. I would be happy to work with you or the SMIL community  
> to figure out how things should be represented. I did make a best  
> effort under give time constraints to try and do things SMIL like  
> for example in the spec you see things like:
> <ref src="">
>  <param name="mood" value="surly" valuetype="data"/>
>  <param name="accessories" value="baseball-cap,nose-ring"  
> valuetype="data"/>
> </ref>
> In the spec here:
> Which lead to templates being represented how they are.. but I  
> understand its not as clean as it could be and I am open to  
> suggestions on how we can improve it and make it more likely a 3rd  
> party real world player could play the format.
>> The statement from the blog "The SMIL spec has evolved over time and
>> has become famous for being very large and complicated to implement  
>> in
>> a real world player" may be true for the specification as a whole,  
>> but
>> not for a domain-specific subset ;)  Just look at SVG or DAISY as
>> prime examples of standards that integrate only the strictly-
>> necessary
>> parts of SMIL.
> Right, at this initial stage of development its not even really  
> ready for a domain-specific subset specification, just help and  
> guidance to make things as smil like as possible, then eventually we  
> can think about efforts in this area.
>> The claim that "Another nice feature of SMIL xml is that it is
>> extensible for custom components" may be true indeed, but this is not
>> quite achieved with the proposed format, as it doesn't conform to the
>> extensibility guidelines.
> Yea I did not mean to say that I strictly conformed to the  
> extensible guidelines only that the 'format is extensible', and that  
> it would be a good direction for the project to go and I am making  
> efforts in that direction.
>> I am looking forward to hearing your thoughts. Feel free to correct  
>> me
>> if I got something wrong ! :)
>> I assume the "public-smil" and "wikivideo-l" mailing lists are most
>> appropriate to continue this discussion, but I also CC'ed the more
>> mature WikiMedia technical lists to ensure this message reaches "whom
>> it may concern" :)
> wikivideo-l is a fine list for this sort of thing.
> --michael