Re: Draft Proposal for Assigning Media Types

Mark Nottingham wrote:

> That's an issue, not a requirement. The question I was trying to get to 
> was whether we need to allow open-ended sets (like image/*) 
> specifically, or just closed sets. I do wonder whether the ability to 
> say "I'd like an image; don't care what format you use, even if I've 
> never heard of it" is useful in a Web services context.
> 

The use case I had in mind was to allow all the image formats that are 
well-know, standard and well-supported. If an unknown format is sent 
this would result in some sort of app level fault. Another alternative 
is to enumerate the various formats that are supported. E.g., 
"image/jpeg image/png ..."

> Once we go beyond restricting the content of the attribute and talk 
> about the content itself as having properties (such as media type), we 
> stumble into full content negotiation (e.g., CC/PP, conneg, etc), which 
> is very much out of scope for both WGs. If we want to bring it in-scope, 
> we should leverage external work that's been going on for nearly a 
> decade, rather than trying to reinvent it in a TF with four participants.
> 

All I am looking for really is a way to declaratively say that attribute 
"mediaType" can have a value from amongst a set of values (and we can 
discuss whether that should be "type/*" or enumeration of all accepted 
values or both). The only way I can do this is without using schema 
extensibility points is by defining my own attribute in my namespace. 
Unfortunately, having everyone define their own attributes does not 
provide any interop.

> Unless we have concrete use cases that absolutely require this kind of 
> negotiation, I believe it would be more prudent to stick with a limited 
> facility like Gudge outlined, if at all possible.
> 

I do have a concrete usecase -- image/*
If you look at WSDL 1.1 MIME binding [1] it is extremely useful to have 
a mime:content element with a type attribute with a value of 'image/*' 
or have two mime:content elements as children of the same mime:part with 
type attribute with a values of 'image/gif' and 'image/png' respectively 
(specifying alternate media-types). One of the short-coming of WSDL 1.1 
MIME binding is that it provides this information only at the WSDL 
message part levels. So if one has binary data that is 'embedded' inside 
a part there is no way to describe the media type of this embedded 
binary data. XML schema is the logical choice, but if we don't allow 
users to specify a list of media-types (or '*') the description 
abilities will be severely hampered.

-Anish
--

[1] http://www.w3.org/TR/wsdl.html#_Toc492291084

-Anish
--

> 
> On Mar 22, 2004, at 3:43 PM, Anish Karmarkar wrote:
> 
>> I had assumed that allowing something like 'image/*' was a 
>> requirement. See XMLP issue 443 [1] (3rd bullet item).
>>
>> -Anish
>> -- 
>>
>> [1] http://www.w3.org/2000/xp/Group/xmlp-issues#x443
>>
>>
>> Umit Yalcinalp wrote:
>>
>>> Mark Nottingham wrote:
>>>
>>>> Do we have use cases where wildcarding is required? It makes sense 
>>>> in some MIME and HTTP situations, but I'm not so sure about Web 
>>>> services.
>>>
>>> I think it is similar to HTTP/MIME. Think about image/*. At the time 
>>> of when you construct a schema, not knowing the specific type but 
>>> knowing that a binary element represents an image is a reasonable 
>>> thing to do. Sending gif or jpeg attachment and indicating the actual 
>>> type in the document is very common use case. Further, it seems to me 
>>> that there is a well established usage pattern due to HTTP/MIME that 
>>> we would be very restrictive if we were to not to allow wildcards.
>>> --umit
>>>
>>>>
>>>>
>>>>
>>>> On Mar 17, 2004, at 3:10 PM, Umit Yalcinalp wrote:
>>>>
>>>>>  Ok, maybe I did not grasp exactly what you are getting at.
>>>>>
>>>>>  Are you trying to combine the two distinct cases of declaring the 
>>>>> actual media type and the accepted media type into one attribute?
>>>>>
>>>>>  As far as I see, and as you point out, dealing with wildcards is a 
>>>>> real problem (image/*) because the value space for the attribute 
>>>>> when declared and when used is going to be different. This is why 
>>>>> in our original proposal, we defined two distinct attributes, one 
>>>>> for the schema and one for the document. I am not sure whether we 
>>>>> can combine these two distinct requirements into one easily because 
>>>>> of reconciling the wildcards via the schema. As a matter of fact, 
>>>>> we discussed this in detail during one of the WSDL f2f meetings, 
>>>>> and could not find a good solution, hence the current proposal.
>>>>>
>>>>>  Just to clarify, I am not married to with having two attributes 
>>>>> ;-). I just can not see a solution with a single attribute without 
>>>>> the wildcard problem.
>>>>>
>>>>>  --umit
>>>>>
>>>>>
>>>>>  Martin Gudgin wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Mark Nottingham [mailto:mark.nottingham@bea.com]
>>>>> Sent: 11 March 2004 17:26
>>>>> To: Martin Gudgin
>>>>> Cc: Anish Karmarkar; public-ws-media-types@w3.org; Umit Yalcinalp
>>>>> Subject: Re: Draft Proposal for Assigning Media Types
>>>>>
>>>>> So it looks like we're back to square one.
>>>>>
>>>>> Not quite! After sleeping on this ( for about a week ;-) ) I awoke 
>>>>> this
>>>>> morning with a solution; Fixed values! Here is an example schema.
>>>>>
>>>>> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
>>>>>            targetNamespace='http://www.w3.org/2004/03/MediaTypes'
>>>>>              xmlns:tns='http://www.w3.org/2004/03/MediaTypes' >
>>>>>  <xs:attribute name='MediaType' type='tns:MediaType' />
>>>>>  <xs:simpleType name='MediaType' >
>>>>>   <xs:restriction base='xs:string' >
>>>>>    <xs:pattern value='{pattern for media types goes here}' />
>>>>>   </xs:restriction>
>>>>>  </xs:simpleType>
>>>>> </xs:schema>
>>>>>
>>>>>
>>>>> <xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
>>>>>            targetNamespace='http://example.org/myservice'
>>>>>            xmlns:tns='http://example.org/myservice'
>>>>>              xmlns:mt='http://www.w3.org/2004/03/MediaTypes' >
>>>>>
>>>>>   <xs:import namespace='http://www.w3.org/2004/03/MediaTypes' />
>>>>>
>>>>>   <xs:element name='Person' type='tns:Person' />
>>>>>   <xs:complexType name='Person' >
>>>>>    <xs:sequence>
>>>>>     <xs:element name='Name' type='xs:string' />
>>>>>     <xs:element name='Portrait' type='tns:Portrait' />
>>>>>     <xs:element name='Signature' type='tns:Signature' />
>>>>>    </xs:sequence>
>>>>>   </xs:complexType>
>>>>>
>>>>>   <xs:complexType name='Portrait' >
>>>>>    <xs:simpleContent>
>>>>>     <xs:extension base='xs:base64Binary' >
>>>>>      <xs:attribute ref='mt:MediaType' fixed='image/jpeg' 
>>>>> required='true'
>>>>> />
>>>>>     </xs:extension>
>>>>>    </xs:simpleContent>
>>>>>   </xs:complexType>
>>>>>
>>>>>   <xs:complexType name='Signature' >
>>>>>    <xs:simpleContent>
>>>>>     <xs:extension base='xs:base64Binary' >
>>>>>      <xs:attribute ref='mt:MediaType'
>>>>> fixed='application/pkcs7-signature' required='true' />
>>>>>     </xs:extension>
>>>>>    </xs:simpleContent>
>>>>>   </xs:complexType>
>>>>>
>>>>> </xs:schema>
>>>>>
>>>>>
>>>>> The required='true' just mandates that the attribute has to appear in
>>>>> the instance and does not affect the workings of the proposal.
>>>>>
>>>>> The only problem I can see with this is that you can't say image/*.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Gudge
>>>>>
>>>>>
>>>>> Are we agreed that we should say something to Schema about this?
>>>>>
>>>>>
>>>>> On Mar 11, 2004, at 5:08 PM, Martin Gudgin wrote:
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com]
>>>>> Sent: 11 March 2004 22:51
>>>>> To: Anish Karmarkar
>>>>> Cc: Mark Nottingham; Martin Gudgin; public-ws-media-types@w3.org
>>>>> Subject: Re: Draft Proposal for Assigning Media Types
>>>>>
>>>>>
>>>>>
>>>>> Anish Karmarkar wrote:
>>>>>
>>>>>
>>>>> This approach does not work if I have two elements of type
>>>>> base64Binary occurring in the same wsdl/schema and their
>>>>>
>>>>> media-types
>>>>>
>>>>> are different. E.g., I have element A with media-type of
>>>>>
>>>>> image/jpeg
>>>>>
>>>>> and another element B with media-type of
>>>>>
>>>>> application/octet-stream and
>>>>>
>>>>> I want to indicate in the schema the media-type of each element.
>>>>>
>>>>> Given that both the elements will use the same MediaType
>>>>>
>>>>> attribute, I
>>>>>
>>>>> cannot define/redefine the MediaType attribute to satisfy
>>>>>
>>>>> the mutually
>>>>>
>>>>> exclusive media-types.
>>>>>
>>>>> May be I misunderstood the suggestion.
>>>>>
>>>>> That is what I understood as well. Gudge, could you clarify?
>>>>>
>>>>> No, you're correct. I only realised this limitation after
>>>>>
>>>>> I'd sent my
>>>>>
>>>>> previous mail and hadn't had chance to point it out myself.
>>>>>
>>>>> :-(
>>>>>
>>>>> Gudge
>>>>>
>>>>>
>>>>> I also don't like the idea of having everyone defining a
>>>>>
>>>>> schema for an
>>>>>
>>>>> attribute in a namespace that is owned by someone else.
>>>>>
>>>>> Kinda goes
>>>>>
>>>>> against accepted practices.
>>>>>
>>>>> -Anish
>>>>> -- 
>>>>>
>>>>> Mark Nottingham wrote:
>>>>>
>>>>>
>>>>> On Mar 11, 2004, at 4:58 AM, Martin Gudgin wrote:
>>>>>
>>>>>
>>>>> We could do it today, here's one option;
>>>>>
>>>>> 1.    Write a schema which defines xop:MediaType
>>>>>
>>>>> attribute as the open
>>>>>
>>>>> pattern for media types
>>>>>
>>>>> 2.    Write a second schema that redefines the type of
>>>>>
>>>>> xop:MediaType
>>>>>
>>>>> to be some restriction of the media type pattern, e,g,
>>>>>
>>>>> image/jpeg
>>>>>
>>>>> 3.    Ref xop:MediaType attribute in second schema from
>>>>>
>>>>> schema in
>>>>>
>>>>> WSDL.
>>>>>
>>>>>
>>>>> Doing it in regex? Oof.
>>>>>
>>>>>
>>>>> Alternatively we could also just tell people to write a
>>>>>
>>>>> schema for
>>>>>
>>>>> the xop namespace that defines a MediaType attribute with the
>>>>> required values.
>>>>>
>>>>>
>>>>> So, we supply the name, the supply the substance? I could
>>>>>
>>>>> live with
>>>>>
>>>>> that. Umit, Anish?
>>>>>
>>>>>
>>>>>
>>>>> WSDL tools would process either of the above just fine.
>>>>>
>>>>> Gudge
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>>>>> Sent: 11 March 2004 02:33
>>>>> To: Mark Nottingham
>>>>> Cc: public-ws-media-types@w3.org; Umit Yalcinalp; Martin Gudgin
>>>>> Subject: Re: Draft Proposal for Assigning Media Types
>>>>>
>>>>> Mark Nottingham wrote:
>>>>>
>>>>>
>>>>> It's probably safest to ask Gudge to characterise exactly
>>>>>
>>>>> what we need
>>>>>
>>>>>
>>>>> :)
>>>>>
>>>>>
>>>>> LOL.
>>>>>
>>>>> I believe Gudge was talking about using substitution
>>>>>
>>>>> groups and
>>>>>
>>>>> concluded that one could not do that with attributes.
>>>>>
>>>>>
>>>>> All that I'm saying is that we had what seemed to be a
>>>>>
>>>>> reasonable
>>>>>
>>>>> requirement that Schema couldn't fulfil. We should give that
>>>>> information to the Schema WG as input to their process.
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> On Mar 10, 2004, at 5:36 PM, Anish Karmarkar wrote:
>>>>>
>>>>>
>>>>> Mark,
>>>>>
>>>>> Are you suggesting that we ask that XML schema support
>>>>>
>>>>> attribute
>>>>>
>>>>> substitution group?
>>>>>
>>>>> Even if there were a attribute substitution group, that
>>>>>
>>>>> would still
>>>>>
>>>>>
>>>>> be a problem because one of the goals was to have a
>>>>>
>>>>> "standard"
>>>>>
>>>>> attribute in a namespace that would indicate the
>>>>>
>>>>> media type of
>>>>>
>>>>> base64Binary data in a doc instance.
>>>>>
>>>>> -Anish
>>>>> -- 
>>>>>
>>>>> Mark Nottingham wrote:
>>>>>
>>>>>
>>>>> Based on our discussion in Cannes, I'm not opposed to the
>>>>>
>>>>> outlined
>>>>>
>>>>>
>>>>> approach. However, I think we (WSDL and XMLP) should
>>>>>
>>>>> raise an issue
>>>>>
>>>>>
>>>>> with XML Schema regarding the ability to constrain an
>>>>>
>>>>> attribute in
>>>>>
>>>>>
>>>>> the manner we would have liked to.
>>>>> regards,
>>>>> On Feb 10, 2004, at 11:39 PM, Anish Karmarkar wrote:
>>>>>
>>>>>
>>>>> Umit Yalcinalp wrote:
>>>>>
>>>>>
>>>>> Mark Nottingham wrote:
>>>>>
>>>>>
>>>>> Umit,
>>>>>
>>>>> Thanks for the proposal. A few comments;
>>>>>
>>>>>
>>>>>
>>>>> Hi Mark,
>>>>> I am glad that finally we are moving on. ;-) Thanks for
>>>>>
>>>>> your comments.
>>>>>
>>>>>
>>>>> * It seems like there's a lot of
>>>>>
>>>>> SOAP/WSDL/MTOM-specific language
>>>>>
>>>>>
>>>>> and rationale in this draft. Although I understand
>>>>>
>>>>> this work is
>>>>>
>>>>>
>>>>> motivated by Web services, it's critical that any
>>>>>
>>>>> mechanism like
>>>>>
>>>>>
>>>>> this gets the broadest possible adoption, so that Web
>>>>> services stacks can leverage this information in
>>>>>
>>>>> any XML it
>>>>>
>>>>> comes across,
>>>>>
>>>>>
>>>>> not just those that have been born (and will die) in a
>>>>>
>>>>> controlled
>>>>>
>>>>>
>>>>> SOAP message exchange.
>>>>>
>>>>>
>>>>>
>>>>> That is an interesting point. The note only addresses the
>>>>> declaration of the expected and actual media-type in the
>>>>> schema and since there is no established support for media
>>>>>
>>>>> types in the
>>>>>
>>>>>
>>>>> schema. The motivation, however, is definitely
>>>>>
>>>>> coming from Web
>>>>>
>>>>> Services angle, wouldn't you agree?  We are
>>>>>
>>>>> jointly working
>>>>>
>>>>> towards publishing this note as WSD and XMLP wgs.
>>>>>
>>>>> Hence, I see
>>>>>
>>>>> that it is only natural that we indicate why we decided
>>>>>
>>>>> to do this
>>>>>
>>>>>
>>>>> and use our starting points as references. If you
>>>>>
>>>>> would like
>>>>>
>>>>> to suggest additional points to be added, would you please
>>>>>
>>>>> send them.
>>>>>
>>>>>
>>>>>
>>>>> I think we need to achieve a careful balance here. It
>>>>>
>>>>> would be good
>>>>>
>>>>>
>>>>> to make the mechanism generic enough that non-Web
>>>>>
>>>>> services related
>>>>>
>>>>>
>>>>> XML technologies can leverage/utilize this if they
>>>>>
>>>>> chooses to do so.
>>>>>
>>>>>
>>>>> I think the proposal achieves that. It would be good to
>>>>>
>>>>> call that
>>>>>
>>>>>
>>>>> out. But I don't think we should go too far and say
>>>>>
>>>>> that this
>>>>>
>>>>> is
>>>>> *the* mechanism for representing media-types for all XML
>>>>> technologies (not sure if that is what you meant).
>>>>>
>>>>>
>>>>> * Some rationale needs to be given as to why only media
>>>>> types, instead of content types, are addressed.
>>>>>
>>>>>
>>>>> I was going to send an email regarding this. I don't see
>>>>>
>>>>> why this
>>>>>
>>>>>
>>>>> should be restricted to media types only. I think we
>>>>>
>>>>> should allow
>>>>>
>>>>>
>>>>> content-types. The rationale for doing so is --
>>>>>
>>>>> media types
>>>>>
>>>>> RFCs are allowed to specify mandatory parameters.
>>>>>
>>>>> Makes sense?
>>>>>
>>>>> * The document refers to problems with using URIs in
>>>>>
>>>>> the content
>>>>>
>>>>>
>>>>> of the mediaType attribute. What are they?
>>>>>
>>>>>
>>>>>
>>>>> I did not want to repeat the discussions that have
>>>>>
>>>>> occured in XMLP
>>>>>
>>>>>
>>>>> meetings. It appears that it would be useful to
>>>>>
>>>>> repeat the
>>>>>
>>>>> discussion in the document as well. I will do that.
>>>>>
>>>>>
>>>>> * The acceptableMediaTypes attribute effectively
>>>>>
>>>>> defines a
>>>>>
>>>>> protocol. This seems very application-specific,
>>>>>
>>>>> hides a lot
>>>>>
>>>>> of information in ways that isn't accessible to
>>>>>
>>>>> XML tools,
>>>>>
>>>>> and reproduces a number of problems that are already
>>>>>
>>>>> evident in HTTP
>>>>>
>>>>>
>>>>> content negotiation. Why is it necessary to define
>>>>>
>>>>> this mechanism
>>>>>
>>>>>
>>>>> at all, when it's just as viable to use Schema to
>>>>>
>>>>> constrain what
>>>>>
>>>>>
>>>>> values are acceptable (for example)?
>>>>>
>>>>>
>>>>>
>>>>> I am not sure I understand what you are proposing as an
>>>>>
>>>>> alternate
>>>>>
>>>>>
>>>>> approach.
>>>>> We simply have two problems at hand.
>>>>> (1) declaring the possible range of values that
>>>>>
>>>>> binary data
>>>>>
>>>>> may have (that is known) when schema is created. (image/*)
>>>>> (2) declaration of the actual media type that is
>>>>>
>>>>> specified by the
>>>>>
>>>>>
>>>>> document. (image/jpeg) For (1), we have discussed
>>>>>
>>>>> several ways of
>>>>>
>>>>>
>>>>> capturing this information in  the WSDL wg, namely
>>>>>
>>>>> declaring the
>>>>>
>>>>>
>>>>> same information via Schema annotations , Schema
>>>>>
>>>>> notations, as
>>>>>
>>>>> well as replicating the possible range of values with
>>>>>
>>>>> additional
>>>>>
>>>>>
>>>>> types that mimic the media type hierarchy.
>>>>> After discussing the possibilities at our f2f
>>>>>
>>>>> meetings, an
>>>>>
>>>>> attribute indicating the range of possible values for a
>>>>>
>>>>> media-type
>>>>>
>>>>>
>>>>> appeared to be the simplest way of doing so [1]. Note
>>>>>
>>>>> the current
>>>>>
>>>>>
>>>>> proposal is equivalent to using Schema Annotations. The
>>>>>
>>>>> attribute
>>>>>
>>>>>
>>>>> value could  be also incorporated within an
>>>>>
>>>>> appinfo element
>>>>>
>>>>> and for all technical purposes, IMO, it is equivalent to
>>>>>
>>>>> the proposal
>>>>>
>>>>>
>>>>> we circulated.
>>>>> Are you suggesting that we should utilize Schema
>>>>>
>>>>> Annotations
>>>>>
>>>>> instead or are you suggesting another way of
>>>>>
>>>>> accomplishing the
>>>>>
>>>>> same thing? If you are suggesting that we constrain the
>>>>>
>>>>>  range of
>>>>>
>>>>>
>>>>> values that are possible to declare an media type, lets
>>>>> discuss what the acceptable set should be to avoid
>>>>>
>>>>> the content
>>>>>
>>>>> negotiation
>>>>>
>>>>>
>>>>> problems that you are referring to. We were aware
>>>>>
>>>>> that this is
>>>>>
>>>>> rather a liberal set.
>>>>>
>>>>>
>>>>> * Section four appears to define a new type of
>>>>>
>>>>> Information Item.
>>>>>
>>>>>
>>>>> Is this really necessary? Indeed, why is this section
>>>>>
>>>>> necessary
>>>>>
>>>>>
>>>>> at all?
>>>>>
>>>>>
>>>>>
>>>>> This is to accomplish (2), namely the document needs to
>>>>>
>>>>> indicate
>>>>>
>>>>>
>>>>> the "actual" media-type of the binary data. Again, it
>>>>>
>>>>> is by using
>>>>>
>>>>>
>>>>> an additional attribute that the "binary" element would
>>>>>
>>>>> carry and
>>>>>
>>>>>
>>>>> indicate the media-type of the element in the document. I
>>>>> don't think that we can get away by not doing this, namely
>>>>>
>>>>> declare only
>>>>>
>>>>>
>>>>> (1) the range of expected media types but not say
>>>>>
>>>>> anything about
>>>>>
>>>>>
>>>>> the actual (concrete) media type  in the document
>>>>>
>>>>> itself. The
>>>>>
>>>>> document is always required to indicate its "concrete"
>>>>>
>>>>> media type,
>>>>>
>>>>>
>>>>> otherwise media-type declared in (1) such as (*/*)
>>>>>
>>>>> would allow any
>>>>>
>>>>>
>>>>> content to appear and would not be very useful for
>>>>> interpreting the media type.
>>>>> Therefore, I would appreciate if you could clarify why
>>>>>
>>>>> you review
>>>>>
>>>>>
>>>>> this section to be redundant. If it is the spec
>>>>>
>>>>> language used that
>>>>>
>>>>>
>>>>> may be confusing, lets discuss.
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Thanks.
>>>>> --umit
>>>>> [1]
>>>>>
>>>>>
>>>>> http://lists.w3.org/Archives/Public/www-ws-desc/2003Sep/0218.html
>>>>>
>>>>> -- 
>>>>> Mark Nottingham   Principal Technologist
>>>>> Office of the CTO   BEA Systems
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Mark Nottingham   Principal Technologist
>>>>> Office of the CTO   BEA Systems
>>>>>
>>>>>
>>>>> -- 
>>>>> Mark Nottingham   Principal Technologist
>>>>> Office of the CTO   BEA Systems
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Mark Nottingham   Principal Technologist
>>>>> Office of the CTO   BEA Systems
>>>>>
>>>>>
>>>>> -- 
>>>>> Umit Yalcinalp
>>>>> Consulting Member of Technical Staff
>>>>> ORACLE
>>>>> Phone: +1 650 607 6154
>>>>> Email: umit.yalcinalp@oracle.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Mark Nottingham   Principal Technologist
>>>>> Office of the CTO   BEA Systems
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Umit Yalcinalp
>>>>> Consulting Member of Technical Staff
>>>>> ORACLE
>>>>> Phone: +1 650 607 6154
>>>>> Email: umit.yalcinalp@oracle.com
>>>>>
>>>>>
>>>>>
>>>>
>>>> -- 
>>>> Mark Nottingham   Principal Technologist
>>>> Office of the CTO   BEA Systems
>>>>
>>>>
> 
> -- 
> Mark Nottingham   Principal Technologist
> Office of the CTO   BEA Systems
>

Received on Tuesday, 30 March 2004 20:27:10 UTC