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:]
> Sent: Wednesday, 2011 November 16 11:32
> To:
> Subject: [docbook] Re: markup for mediaobject parameters
>
> "Grosso, Paul" <> 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
