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"html", 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