headers
David Booth | 4 Oct 2004 18:06
Picon
Favicon

Proposed media type registration: application/wsdl+xml


The proposed registration below is for a media type
"application/wsdl+xml" for use with WSDL 2.0 documents.
The registration will be requested on behalf
of the W3C Web Services Description Working Group.
WSDL 2.0 documents are used to describe Web services.
The specification of the WSDL 2.0 language itself
is available at http://www.w3.org/TR/wsdl20 .
This media type definition appears in
http://www.w3.org/TR/wsdl20#ietf-draft , which will
be updated as necessary.  (The version below is the most
recent.)

This proposed registration is for community review and
will be submitted to the IESG for review, approval, and
registration with IANA at a later stage.

The Last Call period for WSDL 2.0 ends 4 October 2004.
However, because of this late notification, the deadline
for comments on the media type registration has been
extended to 18 October 2004.

=======================================================

To: ietf-types <at> iana.org 
Subject: Registration of media type application/wsdl+xml

Type name:
	application
(Continue reading)

Permalink | Reply | 1 comment |
headers
murata | 8 Oct 2004 03:49
Picon

Fw: Re: XML media types, charset, TAG findings


Forwarded by MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
----------------------- Original Message -----------------------
From:    Bjoern Hoehrmann <derhoermi <at> gmx.net>
To:      chris <at> w3.org
Date:    Thu, 07 Oct 2004 17:27:53 +0200
Subject: Re: XML media types, charset, TAG findings
----

* Chris Lilley wrote:
>Coupled with the deprecation of the text/xml and
>text/xml-external-parsed-entity types (and thus insulation from the
>particular encoding testrictions of text/*) we are now, in this revision
>of the document, in a position to be a little stronger:
>
>  The encoding declaration in an XML document and the charset (if
>  provided) MUST be consistent.

That is insufficient as it does not define what it means for these to be
consistent, how implementations are required to determine whether this
requirement has been met and what processors are required to do when
these are determined to be inconsistent. Without a complete proposal it
is most difficult to cite any reactions on this matter. I would
generally support removing the often ignored complexity that the charset
parameter introduces, with your proposal however, even if completely
specified, I would worry that this increases the complexity rather than
removing it in which case this would seem counter-productive.
--------------------- Original Message Ends --------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
murata | 8 Oct 2004 03:48
Picon

Fw: XML media types, charset, TAG findings


Forwarded by MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
----------------------- Original Message -----------------------
From:    Chris Lilley <chris <at> w3.org>
To:      MURATA Makoto <EB2M-MRT <at> asahi-net.or.jp>, Dan Kohn <dan <at> dankohn.com> (FAMILY Given)
Date:    Thu, 7 Oct 2004 16:44:24 +0200
Subject: XML media types, charset, TAG findings
----

Hello all,

In the approved TAG finding

Internet Media Type registration, consistency of use
TAG Finding 3 June 2002 (Revised 4 September 2002)

a specific criticism of RFC 3023 is raised
3. Consistency in Communicating Character Encoding
http://www.w3.org/2001/tag/2002/0129-mime#char-encoding

and the conclusion is

>> Thus there is no ambiguity when the charset is omitted, and the
>> STRONGLY RECOMMENDED injunction to use the charset is misplaced for
>> application/xml and for non-text "+xml" types. Consequently, for XML
>> representations, server-side applications SHOULD only supply a
>> charset header when there is complete certainty as to the encoding in
>> use. Otherwise, an error will cause a perfectly usable representation
>> to be rejected by an architecturally sound client.
(Continue reading)

Permalink | Reply | 0 comments |
headers
murata | 8 Oct 2004 03:48
Picon

Fw: Re: XML media types, charset, TAG findings


Forwarded by MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
----------------------- Original Message -----------------------
From:    Bjoern Hoehrmann <derhoermi <at> gmx.net>
To:      Chris Lilley <chris <at> w3.org>
Date:    Thu, 07 Oct 2004 19:49:32 +0200
Subject: Re: XML media types, charset, TAG findings
----

* Chris Lilley wrote:
>My preference would be to not have a redundant charset parameter, since
>that would remove the ambiguity. However, I realize that people are
>uncomfortable with that and thus propose this solution.

It seems to me that the only difference between requiring applications
to ignore the charset parameter (regardless of whether it is allowed or
not) and your proposal is that with your proposal applications would be
required to report conflicts in some yet unknown way. I am not sure why
anyone would be more comfortable with your proposal as I do not think
that they are uncomfortable with that due to lack of error reporting.

>Consistent means that the encoding determined by
>F Autodetection of Character Encodings (Non-Normative)
>http://www.w3.org/TR/REC-xml/#sec-guessing
>
>is either the same as the value of the charset pArameter, or the charset
>parameter is not provided.

That's still not clear to me; are e.g. "l1" and "iso-8859-1" "the same"?
--------------------- Original Message Ends --------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
murata | 8 Oct 2004 03:49
Picon

Fw: Re: XML media types, charset, TAG findings


Forwarded by MURATA Makoto (FAMILY Given) <EB2M-MRT <at> asahi-net.or.jp>
----------------------- Original Message -----------------------
From:    Chris Lilley <chris <at> w3.org>
To:      Bjoern Hoehrmann <derhoermi <at> gmx.net>
Date:    Thu, 7 Oct 2004 17:56:03 +0200
Subject: Re: XML media types, charset, TAG findings
----

On Thursday, October 7, 2004, 5:27:53 PM, Bjoern wrote:

BH> * Chris Lilley wrote:
>>Coupled with the deprecation of the text/xml and
>>text/xml-external-parsed-entity types (and thus insulation from the
>>particular encoding testrictions of text/*) we are now, in this revision
>>of the document, in a position to be a little stronger:
>>
>>  The encoding declaration in an XML document and the charset (if
>>  provided) MUST be consistent.

BH> That is insufficient as it does not define what it means for these to be
BH> consistent, how implementations are required to determine whether this
BH> requirement has been met and what processors are required to do when
BH> these are determined to be inconsistent. Without a complete proposal it
BH> is most difficult to cite any reactions on this matter. I would
BH> generally support removing the often ignored complexity that the charset
BH> parameter introduces, with your proposal however, even if completely
BH> specified, I would worry that this increases the complexity rather than
BH> removing it in which case this would seem counter-productive.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane