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 
. You will ultimately adopt only a minute portion of SMIL, probably
smaller that the Tiny Profile  ! 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
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  to your refs, instead of using param.
There's an open-source project called LimSee3 , 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.
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
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"
html", although I'm
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
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
into media objects using nested "param" tags (and "name" +
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
the EDL syntax ?
It would be great if the final format was
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
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:
<param name="mood" value="surly" valuetype="data"/>
<param name="accessories" value="baseball-cap,nose-ring"
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
a real world player" may be true for the specification as a whole,
not for a domain-specific subset ;) Just look at SVG or DAISY as
prime examples of standards that integrate only the strictly-
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
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
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.