Re: Request for review: application/evd+xml media type

Yves Lafon <[email protected]> Mon, 18 Jul 2011 15:41:13 -0400 (EDT)
Newsgroups gmane.ietf.types,gmane.ietf.xml-mime
Message-ID <[email protected]>
On Thu, 7 Jul 2011, Bjoern Hoehrmann wrote:

Thanks Bj=F6rn, here is the revised version of the media type definition:

Type name:

     application
Subtype name:

     evd+xml
Required parameters:

     none
Optional parameters:

     charset
     This parameter has identical semantics to the charset parameter of the =

'application/xml' media type as specified in [RFC 3023].
Encoding considerations:

     Identical to those of 'application/xml' as described in [RFC 3023], =

section 3.2, as applied to the EventDescriptions document.
Security considerations:

     Same as that of Section 10 in [RFC 3023].
Interoperability considerations:

     There are no known interoperability issues.
Published specification:

     Web Services Event Descriptions (this specification).
Applications which use this media type:

     No known applications currently use this media type.
Additional Information:

     Magic number(s):
     None.

     File extension(s):
     evd

     Fragment identifiers:
     An EventDescriptions fragment identifier references a particular Event =

Type within an EventDescriptions document. The Event Type referenced is =

the Event Type with the @id attribute whose normalized value (per =

[xml:id]) equals that of the fragment identifier component.

     For example, if the EventDescriptions document from Example 4-1 were =

located at "http://www.example.com/eventtypes/oceanwatch", the following =

URI references the Event Type defined in lines 12-14: =

http://www.example.com/eventtypes/oceanwatch#WindReportEvent.

     Macintosh file type code(s):
     No Macintosh file type code defined.
Person and email address to contact for further information:

     World Wide Wed Consortium <[email protected]>
Intended usage:

     COMMON
Restrictions on usage:

     none.
Author/Change controller:

     The WS-EventDescriptions specification is a work product of the World =

Wide Web Consortium's Web Service Resource Access Working Group. The W3C =

has change control over these specifications.


> * Yves Lafon wrote:
>> Here is the registration document for the application/evd+xml media
>> type [1] by the W3C Web Services Resource Access Working Group [2].
>
> Has this been submitted before? It seems to me that the document has had
> Candidate Recommendation status for a couple of months, and W3C policy
> is to submit on entering Last Call, but there is nothing in my archives.
>
>> <<<
>> This appendix defines the 'application/evd+xml' media type which can be
>> used to describe EventDescription documents serialized as XML.
>>
>> MIME media type name:
>
> You are using an outdated template, the current template is in RFC 4288.
> The current templates structures and names some fields differently.
>
>> Security considerations:
>>
>>     none
>
> Well, at the very least you should point out that the ones in RFC 3023
> are likely to apply to implementations of the specific type here aswell.
>
>> Interoperability considerations:
>>
>>     There are non known interoperability issues.
>
> This looks like a typo.
>
>>     Fragment identifiers:
>>     An EventDescriptions fragment identifier references a particular Eve=
nt
>> Type within an EventDescriptions document. The Event Type referenced is
>> the Event Type with the @id attribute whos value equals that of the
>> fragment identifier component.
>
> In addition to the typo, this seems insufficient and I am not sure how
> compatible this is other types and what some people would like to change
> the existing specifications to. I note in particular that you don't say
> whether for instance "#x" would match id=3D' x ' (note the spaces); I also
> note that you don't define the `id` attribute as ID attribute and don't
> say how this works for actual ID attributes or magic ones like xml:id.

This has been clarified, both in the media type definition and in the =

schema associated.

>>     Base URI:
>>     As specified in [RFC 3023] section 6.
>
> The only reason to include this that I can think of is to mislead people
> into thinking RFC 3023 has anything to say on that even though it does
> not. If you don't want to say anything about Base URIs, then don't.

-- =

Baroula que barouleras, au ti=E9u toujou t'entourneras.

         ~~Yves