RE: [docbook] Re: markup for mediaobject parameters

["Grosso, Paul" <pgrosso@ptc.com>]

I'm confused.  I think a lot of what you say below assumes
that you can have more than one *data element within a
*object element, and at least in DocBook 4.0, you cannot.
You can have multiple *object elements within a mediaobject,
but you must have, for example, exactly one videodata within
a videoobject.  So...

> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Wednesday, 2011 November 16 11:32
> To: docbook@lists.oasis-open.org
> Subject: [docbook] Re: markup for mediaobject parameters
> 
> "Grosso, Paul" <pgrosso@ptc.com> writes:
> [...]
> > I wouldn't have put alignment or (viewport) height and width
> > attributes on videodata.  I would think they belong on
> > videoobject which is the element I think of as defining the
> > viewport.  Though I could live with them on videodata, since
> > the information is still available, it just seems wrong to me.
> 
> I believe the motivate was the case where there is more than one
> object (they are alternatives in that case) and they have different
> sizes.

...there can't be more than one videodata within a videoobject,
so what you want isn't making sense to me.

> 
> If you insert the big EPS one, then you want the EPS dimensions. If
> you insert the little JPG one, then you want the JGP dimensions.
> 
> (I'm not entirely convinced, but I believe that was the motivation.)
> 
> > The discussion under imagedata goes to great lengths to explain
> > the subtle differences between viewport and content area, and
> > we have the videoobject element to define the viewport and the
> > videodata element to define the content, and then we go and put
> > the attributes in the wrong place.
> 
> Uhm, they're in the same places, aren't they?

Huh?

> 
> > (And before I forget, we need to add sizing attributes to
> > audioobject and/or audiodata to define the size of the
> > controls or whatever will show to play the audio.)
> 
> Fair enough.
> 
> > I would add the following (optional) attributes to videodata
> > (and audiodata):
> >
> > type
> > classid
> > autostart
> >
> > While these attributes could just be specified using the generic
> > multimedia parameter markup discussed below, I've found that these
> > values require special handling to get things to work across the
> > majority of browsers, so it's best to provide a better handle
> > on them.  Then the generics can generally just be passed through
> > without special processing.
> 
> Fine by me.
> 
> > We would then allow zero or more multimedia parameters as
> > children of videoobject.  These are to specify all the many
> > param elements that may be needed as children of the HTML
> > object element in the resulting HTML.
> >
> > So a proposed schema might look like (ignoring <info>, common
> > atts, and not thinking much about attribute types):
> >
> >  <xsd:element name="videoobject">
> >     <xsd:complexType>
> >       <xsd:sequence>
> >         <xsd:element minOccurs="1" maxOccurs="1" ref="videodata"/>
> >         <xsd:element minOccurs="0" maxOccurs="unbounded"
> >                                        ref="multimediaparam"/>
> >       </xsd:sequence>
> >       <xsd:attribute name="depth" type="xsd:string"/>
> >       <xsd:attribute name="width" type="xsd:string"/>
> >       <xsd:attribute name="align" type="..."/>
> >       <xsd:attribute name="valign" type="..."/>
> >     </xsd:complexType>
> >  </xsd:element>
> >
> >  <xsd:element name="videodata">
> >     <xsd:complexType>
> >       <xsd:attribute name="fileref" type="xsd:string"/>
> >       <xsd:attribute name="entityref" type="xsd:entity"/>
> >       <xsd:attribute name="contentdepth" type="xsd:string"/>
> >       <xsd:attribute name="contentwidth" type="xsd:string"/>
> >       <xsd:attribute name="scale" type="xsd:string"/>
> >       <xsd:attribute name="scalefit" type="xsd:string"/>
> >       <xsd:attribute name="type" type="xsd:string"/>
> >       <xsd:attribute name="classid" type="xsd:string"/>
> >       <xsd:attribute name="autostart" type="xsd:string"/>
> >     </xsd:complexType>
> >   </xsd:element>
> >
> >   <xsd:element name="multimediaparam">
> >     <xsd:complexType>
> >       <xsd:attribute name="name" use="required" type="xsd:NMTOKEN"/>
> >       <xsd:attribute name="value" use="required" type="xsd:string"/>
> >       <xsd:attribute name="valuetype" type="xsd:string"/>
> >     </xsd:complexType>
> >   </xsd:element>
> 
> Don't the params belong in the data? I would have expected to need
> different params for an AVI video than I do for an MP4 video. At least
> sometimes.

There is one videodata per videoobject, so putting the params
within videoobject associates them with exactly one videodata.

paul