MHonArc v2.5.2 -->
















xliff message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]








Subject: Re: [xliff] Mime type values




From: bryan.s.schnabel@exgate.tek.com
To: xliff@lists.oasis-open.org
Date: Tue, 25 Feb 2003 13:47:31 -0800






Hello,

I think the following fulfills the requirement the TC asked me to solve this
morning regarding mimetype, and optional subtypes.

Note; I took a look at the "purpose" model. I like it, but concluded it
would not fit this requirement (this is different because we want to allow
any one item from an enumerated list, with an optional "/. . ." pattern
concatenated to it). 

So I could only come up with the regular expression approach (though I think
this will be easy enough to maintain, as long as the list of media types
remains manageable).

<xsd:simpleType name="mime-typeValueListBlock">
 <xsd:restriction base="xsd:string">
  <xsd:pattern
value="(text|multipart|message|application|image|audio|video|model)(/.+)*"/>

 </xsd:restriction>
</xsd:simpleType>

If we then change the mime-type attributes to this:

<xsd:attribute name="mime-type" type="xlf:mime-typeValueListBlock" . . .

The XSD correctly validates these samples:

mime-type="image/gif"
mime-type="image"
mime-type="application/vnd.fujixerox.docuworks.binder"
mime-type="video"

But rejects these samples:

mime-type="image/"
mime-type="image-gif"
mime-type="image gif"

The regular expression approach also allows mime-typeValueListBlock to be
added to the datatypeValueList union. 
(I investigated a somewhat complex union of enumerations and simpletypes,
but ran into limitations having to do with atomic and list type restrictions
-- I'd be happy to elaborate off line to any one interested in the details).

Please let me know if you think I should push a bit harder on the
mime-typeValueList, or if there might be a better approach.

Thanks,
Bryan