Next in thread → Next in month →

Re: [xliff] Mime type values

From
John Reid <>
Date
2003-02-25T21:56:25+00:00
ID
Thread
Re: [xliff] Mime type values
Hi Bryan,

 

This looks good. I had tried using an enumeration but ran into a problem 
with the pattern. Your enumerated approach does what I want. 

 

BTW: I looked about a bit for a good reference or primer on the 
regular expressions but didn't find anything. Can you recommend anything/

 

thanks,

john

>>> <> 2/25/03 
2:47:31 PM >>>

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

    -----Original 
Message-----
    From: John Reid [mailto:]
    
Sent: Monday, February 24, 2003 9:10 AM
    To: 

    Subject: Re: [xliff] Mime type 
values
    
    Hi Tony, 

    Is there a way we could allow subtype specification in 
the schema
without specifying all the known media subtypes; e.g. "image/gif"? 
In other
words, can we enumerate a list of types with an undefined subtype 
list in a
pattern? If not, I guess we are stuck with listing only the media 
types. 
    cheers, 
    john 

    >>> Tony Jewtushenko 
<> 2/24/03 4:21:56
AM 
>>>
    Hi all: 
    

    An open 1.1 issue
<http://lists.oasis-open.org/archives/xliff/200207/msg00033.html> 
yet to be
fully resolved relates to the list of Mime types. Assuming that we 
only list
the media types and don't attempt to capture subtypes (there's no 
closed
list), according to RFC2046 <http://www.ietf.org/rfc/rfc2046.txt> 
the list
of mime types should be:
    

    text
    image
    
audio
    video
    
application
    multipart
    
message
    
    We could try to list all 
known types in our spec, but I don't
recommend this because the list would be 
both enormous and always
incomplete. However, we could list the basic type 
for each (which are
provided as examples in the RFC 
itiself).
    
    What's the opinion of the 
group?
    
    
Regards,
    Tony
    -- 

    Tony Jewtushenko
<mailto:>
    
Sr. Tools Program Manager        
    direct tel:
+353.1.8039080
    Product 
Management - Tools Technology Team
    Oracle Corporation, 
Ireland

----------------------------------------------------------------
To 
subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
Next in thread → Next in month →