FW: FW: The media type document discussion in the WSD f2f

WG approval of the first WG draft will be on the agenda for tomorrow.

 

________________________________

From: David Fallside [mailto:fallside@us.ibm.com] 
Sent: Wednesday, May 26, 2004 11:29 AM
To: Jonathan Marsh
Cc: w3c-xml-protocol-wg@w3.org
Subject: Re: FW: The media type document discussion in the WSD f2f

 

Jonathan, the XMLP WG discussed the media type doc on its call today.
The WG did not raise any new issues, nor did it have any problem with
the 3 issues (listed below) that WSD WG has resolved. XMLP WG concurs
with publishing the media type doc as a WD as soon as possible.

On behalf of the WG,
David Fallside
Chair, XMLP WG


"Jonathan Marsh" <jmarsh@microsoft.com>



"Jonathan Marsh" <jmarsh@microsoft.com> 
Sent by: xml-dist-app-request@w3.org 

05/25/2004 09:58 PM

 

To

 
<xml-dist-app@w3.org>



cc


"Umit Yalcinalp" <umit.yalcinalp@oracle.com>, "Anish Karmarkar"
<Anish.Karmarkar@oracle.com>



Subject


FW: The media type document discussion in the WSD f2f

 







This mail from Umit details the issues raised by the WSDesc WG on the
Media Type document, as well as three resolutions we'd like to see
implemented prior to publication.

Sorry for the delay, I thought this was addressed to the XMLP list
directly.

-----Original Message-----
From: Umit Yalcinalp [mailto:umit.yalcinalp@oracle.com] 
Sent: Wednesday, May 19, 2004 8:24 PM
To: David Fallside
Cc: Anish Karmarkar; Jonathan Marsh
Subject: FYI: The media type document discussion in the WSD f2f

Hi David,

We discussed the media-types document today in the WSD f2f meeting. The 
wg has identified some issues with the document. We also identified 
resolutions to some of these issues. I wanted to inform you about these 
whole set of issues, the resolved issues and the associated decisions 
for resolutions. We need to decide how to proceed with the document 
based on your review process, what XMLP decides to be a showstopper 
before we can publish the first public draft and how we can proceed so 
that the media-type document is referrable. We went through the same 
exercise today and  identified the  immediately resolvable issues.

Currently, there are 13 issues, 3 of them are resolved. Some of the 
issues are editorial and some are typos/bugs.

Issues:

The first two issues deal with the lack of definition of error
conditions and whether the note should 
recommend actions for indicating errors in the specification explicitly,

i.e. some kind of faulting, etc. 

mt1. possible error condition: mismatch between value of media type 
attribute and pattern -- This is nothing about the content but a
mismatch of the 
acceptedMediaType and the mediaType values. 

mt2. possible error condition: mismatch between the media type attribute

and the actual data (content), i.e. the attribute declares image/jpeg
but the actual content is
not jpeg. 

mt3. Is acceptMediaType the right name for the attribute.
     valid?, expected? permitted? emitted? (suggestions)

mt4. where should appInfo go -- on the type and/or element? 

mt5. remove or describe fully multipart and message in the patterns
-- i.e. the composite types

mt6. acceptedMediaType should be able to be a list

mt7. Consider changing name from mediaType to contentType

mt8. Would like more examples:
 e.g using a static type -- i'm always going to use an image/jpeg. What

would that look like with acceptedMediaType

mt9. Explain why this proposal is limited to base64encoded?

mt10. Explain why */* AND absence means this is opaque application data 
(i.e. application/octet-stream.

mt11. Pattern includes use of priorty -- either explain relationship or
get 
rid of

mt12. How do annotations show up in component model? (currently limited
to 
a "binary information element")

Note: This is in retrospect a recap of issue mt4. 

mt13. Type: accept/acceptedMediaType ? 



Resolved Issues: 

Issue mt5 Proposal: remove composite types
  *** UNAN accepted

Issue mt3 Proposal: rename acceptMediaType to expectedMediaType
  *** UNAN accepted

Issue mt6 Proposal: make expectedMediaType a list
  *** UNAN accepted

As I understand from communicating with Anish that XMLP would request
the name of the attributes to be changed
from mediaType to contentType, in consistent with mt7. I will bring this
up tomorrow during the f2f with the wg which 
should also resolve mt3 in a consistent manner, something like
"expectedContentType". 

In order to go forward, what we need to do is to collect the issues from
XMLP wg and to make the full issue list
that can be resolved. The question we were wondering today was whether
there are showstoppers that 
XMLP wg identified (or when you will get a list of such issues) for
publishing a draft of the note if we were to include the proposed
resolutions
to mt3,4, 5, 6 and 7 as stated above. We were hoping that the
resolutions we have identified are also acceptable
to XMLP as well. This can be done relatively quickly. 

Thanks,

--umit




-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com