OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [docbook] Re: markup for mediaobject parameters


By the way, both videodata and audiodata have a @format
attribute whose declared value is an enumerated list
consisting of graphic types.  This is pretty useless,
since video and audio objects are not graphics.

If we are considering changes to accommodate multimedia,
we might consider making the format attribute CDATA or
something.

Or we could just drop the @format attribute and plan
to use the (proposed) general param mechanism which is
what I have to do at present anyway.

paul

> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Friday, 2011 August 26 16:36
> To: docbook@lists.oasis-open.org
> Subject: RE: [docbook] Re: markup for mediaobject parameters
> 
> 
> 
> > -----Original Message-----
> > From: Norman Walsh [mailto:ndw@nwalsh.com]
> > Sent: Friday, 2011 August 26 16:00
> > To: docbook@lists.oasis-open.org
> > Subject: [docbook] Re: markup for mediaobject parameters


> > [...]
> >
> > What's the "type" that Firefox can't have set sometimes and
> > can it have it set sometimes?
> 
> The media type, such as audio/mpeg or video/x-ms-wmv.  It is
> also an HTML attribute on object:
> http://www.w3.org/TR/html401/struct/objects.html#adef-type-OBJECT
> 
> >
> > > So the only choices I see are to tell them that there is no
> > > support for doing this in DocBook or to suggest they use
> > > something like the keywordset solution.
> >
> > I suggest a third option: that we extend the markup in DocBook to
> > support this case better. I've wanted to more than once but never
> > been motivated to work out the details as you have.
> >
> > What I can't tell is if the best way to do that would be to add new
> > attributes: @type, @autostart, @classid or to add a more general
> > <param name="key" value="value"/> mechanism.
> 
> I suggest the more general (though I might suggest using elements
> instead of attributes, as that is more flexible).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]