RE: markup for mediaobject parameters

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

> -----Original Message-----
> From: Norman Walsh [mailto:ndw@nwalsh.com]
> Sent: Tuesday, 2011 August 30 15:08
> To: Grosso, Paul
> Cc: docbook@lists.oasis-open.org
> Subject: Re: markup for mediaobject parameters

> 
> Could I persuade you to make a concrete proposal for the
> changes that you'd like to see?

For 4.x, I've managed using keywordset as described previously.
It isn't the best markup, but I can make it work, and I 
understand the hesitancy in spending more time on 4.x, so
the rest of this email is about 5.x.

Let's just consider a mediaobject with a single videoobject.
Ignoring <info> (which is for generic metadata, but isn't useful
for media object related information), the only content of 
videoobject is videodata, and videodata has no children (other
than info) and has some attributes, but not enough plus too much.

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.
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.

(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.)

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.

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>

paul