Re: Possibility of an XML Document Type

 Noah,
 I disagree you lose a lot using SOAP with attachments. Why can't
you process the attachments as XML? Why can't you run them in an
obvious way through XSL or XPath? The attachment carries its MIME
type along with it so it's a similar situation as if you had an
xsi:mimeType attribute on the base64 element.
 In attachments case the SOAP processor sees an attachment of
MIME type known to be XML (like text/xml, application/xml,
application/*+xml, application/soap) so it parses the attachment
to a DOM tree (or whatever).
 In embedded element case the SOAP processor sees an element
whose value is of MIME type known to be XML so it parses the
element's value to a DOM tree (or whatever).
 As I wrote in my previous mail, I agree the EmbeddedXML binary
type could be useful, but it should be a part of a type library
as you, too, seem to be suggesting at the end of your post.
 Regards,

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



On Fri, 5 Oct 2001 Noah_Mendelsohn@lotus.com wrote:

 >
 > Several responses to this proposal have come in.  To save email, I'll
 > respond to all I've seen here in one mail.  First, thanks to the many who
 > said this was an interesting direction to explore.
 >
 > Rich Salz writes:
 >
 > >> SOAP with attachments would also address this, right?
 >
 > It's an option, but I think you lose a lot.  You can't process the
 > attachements as XML.  You can't run them in an obvious way through XSL or
 > XPath.  They wouldn't obviously get stored in a database with the message.
 > This option would be for cases where you really want the document in the
 > message.  There will be a cost, for the bin64 or whatever encoding.
 >
 > Andrew Layman writes:
 >
 > >> base64Binary is a format for representing arbitrary data, but hexBinary
 > is also.  We should be able to embed a complete XML document using either
 > encoding.
 >
 > I agree, and in principle others should be possible too.
 >
 > >> This suggests that a distinct attribute is needed, perhaps
 > >> something along the lines of
 >
 > >>           <abc xsi:type="xsd:base64Binary" xsi:mimeType
 > ="application/xml">?
 >
 > Relating it to MIME types seems like a very cool idea, but I'm
 > uncomfortable taking this out of the type system.   In some ways, the
 > architecturally ideal way of doing this is unlikely to be practical.  I
 > think that would be to introduce a new facet into the XSD type system for
 > the binary types.  It would be a facet that would (optionally) indicate
 > "mime type of encoded data".  Then you could derive subtypes of both
 > base64Binary and hexBinary in a clean way.
 >
 > Even lacking this facet, I think we should declare subtypes.  I think I
 > really want to be able to do this typing either in the schema or an
 > instance, and your suggested attribute works only in the instance.  I also
 > feel its quite important to encode this as a type.  In XPath 2 I presumably
 > want to say things like "find all nodes that are nested XML documents", in
 > queries I want to understand this as a return type, etc.  I think this is
 > type information and we should try to represent it as such.
 >
 > This seems to be an area where we miss either multiple inheritance and/or
 > user-defined facets in the XSD type system.  You'd really like to say both
 > of "this is binary, regardless of encoding, and "this is application/xml",
 > regardless of bin64, hex, or other encoding.
 >
 > Thanks to everyone for your encouragement.  I hate to make the spec bigger,
 > but I think that carrying XML inside of SOAP messages is a good thing to be
 > able to do.  Indeed, I think it's needed equally in other XML documents.
 > If so, we should perhaps make the case for the Schema WG to include this in
 > the type library.  Gudge, what think you?
 >
 > ------------------------------------------------------------------------
 > Noah Mendelsohn                                    Voice: 1-617-693-4036
 > Lotus Development Corp.                            Fax: 1-617-693-8676
 > One Rogers Street
 > Cambridge, MA 02142
 > ------------------------------------------------------------------------
 >
 >
 >
 >

Received on Friday, 5 October 2001 10:58:16 UTC