Re: Request for two new media types submitted

* Phil Archer <phil@philarcher.org> [2008-12-03 10:49+0000]
> 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:

oops, one pasto made you scratch your head and write a lot of email;
sorry! .pdr would make more sense, but haven't looked up collisions
yet.

> 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)

I started with the template for SPARQL Query Results XML Format, and
forgot to change it.

Do you have a use case that uses an extension, e.g. a user clicks on a
.pdr files and something clever happens? If not, I'd request no exten-
sion; I see more motivation for media distinction on the wire than in
the filesystem.

> 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.

ahh, fair point.

> 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.

The +xml convention is intended to serve the apps where a generic XML
handler provides some value, perhaps because it dispatches the correct
code based on the root namespace, or perhaps just as a pretty-printer
such as Mozilla's XML renderer. Thus an app seeing application/xxx+xml
has a useful fallback interpretation.

Given where semweb-heads would like to see RDF go, a two-tiered
fallback would indeed make sense. I'm curious what veterans of the
RFC3023 (*/*+xml) discussions suggest.

> 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/

-- 
-eric

office: +1.617.258.5741 32-G528, MIT, Cambridge, MA 02144 USA
mobile: +1.617.599.3509

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.