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

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?

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

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Curiosity will conquer fear even
http://www.oasis-open.org/docbook/ | more than bravery will.--James
Chair, DocBook Technical Committee | Stephens

Attachment: pgpOOpoSHFPBv.pgp
Description: PGP signature



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