Re: Request for two new media types submitted

Bjoern, pleased to meet you and thanks for looking at this.

Eric, thanks very much for your expert help here. Much appreciated.

Ivan questioned the use of text/ for POWDER and I confidently pointed to 
the relevant sentence in RFC3023 saying "no, we're right, honestly." 
Thanks for playing the trump card of the Webarch doc for us.

application/powder+xml is clearly the way to go for POWDER and, 
notwithstanding adverse comment from others, I'll add the template to 
the Description Resources document.

But you've also suggested a file extension (.srx). Two questions:

1. Do you think we really need one? (we've just used .xml so far)
2. If so, just for completeness, can you tell me how you get srx out of 
POWDER? (is .pdr gone? Is there somewhere authoritative cf. the list at 
http://filext.com/alphalist.php?extstart=%5EP)

As for POWDER-S, the problem is the Semantic Extension 
(http://www.w3.org/TR/2008/WD-powder-formal-20081114/#SE). Yes, a 
POWDER-S document is a valid OWL ontology - but it's pretty meaningless 
unless you implement the extension that allows a resource to be an 
instance of a class based on matching its IRI against one or more 
regular expressions. Hence the request for a Media type that is specific 
to POWDER-S.

Logically, we'd probably go for application/powder-s+rdf+xml or maybe 
application/pdrs+rdf+xml but that's getting a bit unwieldy (can you have 
x+y+xml??). And if we were to suggest a new file extension then it would 
probably be pdrs if that's available.

Thanks

Phil.


Eric Prud'hommeaux wrote:
> * Bjoern Hoehrmann <derhoermi@gmx.net> [2008-12-02 18:36+0100]
>> * Phil Archer wrote:
>>> On behalf of the W3C POWDER Working Group I have have today submitted 
>>> two registration requests for Media Types. As cited in those requests, 
>>> the key documentation is section 4 of Protocol for Web Description 
>>> Resources (POWDER): Description Resources [1]. Although this is formally 
>>> published as a working draft, we are close to reaching our Candidate 
>>> Recommendation exit criteria and therefore expect to seek transition to 
>>> Proposed Recommendation later this month.
>>> [1] http://www.w3.org/TR/powder-dr/#assoc
>> As per RFC 4288
>>
>>    As stated previously, standards tree registrations for media types
>>    defined in documents produced by other standards bodies MUST be
>>    described by a formal standards specification produced by that body.
>>    Such specifications MUST contain an appropriate media type
>>    registration template taken from Section 10.
>>
>> I could not find such a template in the document. Also, given that
>> some http://www.w3.org/TR/webarch/#xml-media-types in the W3C think
>>
>>   In general, a representation provider SHOULD NOT assign Internet
>>   media types beginning with "text/" to XML representations.
>>
>> A registration request for text/powder+xml from the W3C should not
>> come without some form of justification for this choice.
> 
> Phil, meet Bjoern. Bjoern is lint for W3C and IETF specs.
>   http://en.wikipedia.org/wiki/Lint_programming_tool
> 
> I propose that POWDER register application/powder+xml for POWDER, and
> use application/rdf+xml for POWDER-S.
>   http://www.ietf.org/rfc/rfc3870.txt
> 
> I think it's handy to include the media type registration in the spec,
> à al http://www.w3.org/TR/rdf-sparql-query/#mediaType .
> 
> Following http://www.w3.org/2002/06/registering-mediatype , and
> assuming you have no preference above being good netizens, I have
> created a template for both (powder+xml and powder-s+xml) with
>   http://www.w3.org/TR/webarch/#xml-media-types
> trumping
>   http://www.rfc-editor.org/rfc/rfc3023.txt
> , i.e. using application/ instead of text/:
> 
> [[
> Type name:
>   application
> 
> Subtype name:
>   powder+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 [RFC3023], section 3.2.
> 
> Encoding considerations:
>   Identical to those of "application/xml" as specified in [RFC3023],
>   section 3.2.
> 
> Security considerations:
> 
>   POWDER is used to make assertions, sometimes socially sensitive,
>   about web resources. Consumers of POWDER should be aware of the
>   source and chain of custody of this data. Security considerations
>   for URIs (Section 7 of [RFC3986]) and IRIs (Section 8 of [RFC3987])
>   apply to the extent that describing resources in POWDER may prompt
>   consumers to retrieve those resources.
> 
> Interoperability considerations:
>   There are no known interoperability issues.
> 
> Published specification:
>   http://www.w3.org/TR/powder-dr/
> 
> Applications which use this media type:
>   No known applications currently use this media type.
> 
> Additional information:
> 
> Magic number(s):
>   As specified for "application/xml" in [RFC3023], section 3.2.
> 
> File extension(s):
>   ".srx"
> 
> Fragment identifiers:
>   Identical to that of "application/xml" as described in RFC 3023
>   [RFC3023], section 5.
> 
> Base URI:
>   As specified in [RFC3023], section 6.
> 
> Macintosh file type code(s):
>   "TEXT"
> 
> Person & email address to contact for further information:
>   Phil Archer <public-powderwg@w3.org>
> 
> Intended usage:
>   COMMON
> 
> Restrictions on usage:
>   None
> 
> Author/Change controller:
>   The POWDER specification is a work product of the World Wide Web
>   Consortium's Protocol for Web Description Resources (POWDER) Working
>   Group. The W3C has change control over these specifications.
> 
> References
> 
> [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
>           RFC 3023, January 2001.
> 
> [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>           Resource Identifier (URI): Generic Syntax", STD 66, RFC
>           3986, January 2005.
> 
> [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
>           Identifiers (IRIs)", RFC 3987, January 2005.
> ]]
> 
> 

-- 

Phil Archer
w. http://philarcher.org/

Received on Wednesday, 3 December 2008 10:49:50 UTC