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.
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
> 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
>> 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
>> 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
>> 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"
> 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
>> 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
>> 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.
|Free forum by Nabble||Edit this page|