W3C home > Mailing lists > Public > public-powderwg@w3.org > December 2008

Re: Request for two new media types submitted

From: Phil Archer <phil@philarcher.org>
Date: Wed, 03 Dec 2008 15:10:26 +0000
Message-ID: <4936A162.90706@philarcher.org>
To: Eric Prud'hommeaux <eric@w3.org>
CC: Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-types@iana.org, Public POWDER <public-powderwg@w3.org>, Ivan Herman <ivan@w3.org>

Eric Prud'hommeaux wrote:
> * 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.

That's life!

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

Our thinking appears to be in alignment. No, we've never discussed 
having a separate file extension for POWDER docs (of any species) so 
let's drop this line of thought and stick with .xml for POWDER and .rdf 
(or .owl) for POWDER-S.

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

Something Bjoern can help us with? Right now it seems we're probably on 
the right track with

application/powder+xml and
application/powder-s+xml  ??


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


Phil Archer
w. http://philarcher.org/
Received on Wednesday, 3 December 2008 15:11:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:42 UTC