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="http://www.w3.org/1999/xhtml", 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="http://www.example.com/herbert.face"> <param name="mood" value="surly" valuetype="data"/> <param name="accessories" value="baseball-cap,nose-ring" valuetype="data"/> </ref>
In the spec here: http://www.w3.org/TR/SMIL3/smil-extended-media-object.html#edef-param
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