- From: David RR Webber (XML) <w3c@drrw.info>
- Date: Wed, 08 Dec 2004 08:25:32 -0500
- To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
- CC: public-ws-media-types@w3.org
Henry, If the goal here is to transport binary payloads across a SOAP interface, then this is all already implemented and available - with packaging extensions to the base SOAP enveloping to handle all that. There is also an open source toolset available here: http://sourceforge.net/projects/ebxmlms I was recently able to send a 110Mb binary using this toolset so I know that it works - and the specification is robust. Thanks, DW Henry S. Thompson wrote: >I have produced these comments at the request of the XML Schema WG, >but the WG has not yet seen them, much less endorsed them. >None-the-less they are intended to be comments specifically from the >perspective of XML Schema, and I hope they may be helpful. > >1) Architecture > >I'm sympathetic to what you're trying to achieve, i.e > > a) Enable e.g. a SOAP message to say "this bit of binary encodes an > application/png image"; > b) Enable e.g. an XML Schema involved in a WSDL doc. to say "the > binary allowed here should be marked (per (a) above) as encoding > one or more of the following media types. . ." > >But I'm not entirely happy with the way you've separated these two >goals and introduced a new mechanism for cross-validation between >them. > >There are already two relevant mechanisms available in XML Schema >which it seems to me would serve your needs much more >straightforwardly. > >The first mechanism is the type-derivation hierarchy; one way to use it >for your purposes goes as follows: > > It makes sense to think about e.g. image/png encoded as base64 as a > _subtype_ of xs:base64Binary. It even makes sense to think about > image/png encoded as base64 as a subtype of image/* encoded as > base64. > > So why not define a family of types in a basic XML Schema for the > xmlmime namespace, one rooted at xs:base64Binary and the other, > parallel, one rooted at xs:hexBinary, as follows: > > xs:base64Binary > | > xmlmime:base64Binary > /|\ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > xmlmime:image xmlmime:text xmlmime:application . . . audio, video > . /|\ . > . / | \ . > . / | \ . > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ > / | \ >xmlmime:text_plain xmlmime:text_xml xmlmime:text_html > >Then you can get rid of xmlmime:expectedMediaType altogether, so that >e.g. > > <xs:complexType name="JPEGPictureType" > type="xs:base64Binary" > xmlmime:expectedMediaType="image/jpeg"/> > > <xs:element name="JPEGPicture" type="tns:JpegPictureType"/> > >becomes simply > > <xs:element name="JPEGPicture" type="xmlmime:image_jpeg"/> > >and you don't need xmlmime:contentType if you're confident of schema >processing, but _if_ you want to be explicit, you can use xsi:type >instead, e.g. > ><Picture xsi:type="xmlmime:image_png">/aWKKapGGyQ=</Picture> > >I realise this doesn't cover the full generality of your proposal, in >so far as you appear to be allowing _any_ kind and number of >'parameters' after the type/subtype. I am not at all sure that's the >right thing to do, and at the very least I think you need some >argumentation to establish the need for that much generality. > >Note furthermore that the general rules for type substitution and >unions can be used to establish arbitary sets of media types, so that >the functionality your now achieve by allowing a list of media types in >is not lost. > >---------------- > >The other mechanism already present in schema reflects the fact that >this problem has been around for a long time. A solution was already >present in SGML DTDs and carried forward into XML DTDs and XML Schema, >namely NOTATION attributes (see [1] and [2]). There is an example in >[2] which directly addresses your concerns, and would allow you to >eliminate xmlmime:expectedMediaType and connect xmlmime:contentType >more clearly to the IETF media type definitions via the URL hierarchy >rooted at http://www.iana.org/assignments/media-types/, e.g. by >changing the example from [2] to read > ><xs:notation name="jpeg" > public="image/jpeg" > system="http://www.iana.org/assignments/media-types/image/png" /> > >Again, on this approach the XML Schema for the xmlmime namespace would >contain declarations for many useful Notations and simple types >derived from NOTATION, for use in WSDL schemas. > >2) Low-level points > >If the discussion above has persuaded you to change the current >design, well and good. If it has not, there are some minor ways in >which the current design could be improved. > >2a) Using xs:string is almost certainly not what you want -- that >makes whitespace variation significant, so that e.g. > xmlmime:contentType="image/png " >is not the same as > xmlmime:contentType="image/png" > >I would recommend xs:token instead. > >2b) Please provide a concrete reference for "IANA media type token". > >2c) In example 1, you probably mean > > <xs:restriction base="xmlmime:base64Binary"> > >2d) In example 4, you probably mean > > <xs:complexType name="JPEGPictureType> > <xs:complexContent> > <xs:restriction base="xmlmime:base64Binary" > xmlmime:expectedMediaType="image/jpeg"/> > </xs:complexContent> > </xs:complexType> > >ht > >[1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#NOTATION >[2] http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#declare-notation > >
Received on Wednesday, 8 December 2004 13:55:01 UTC