Re: Re: Request for two new media types submitted

* Phil Archer <> [2008-12-08 15:54+0000]
> Thanks Eric, your and everyone's input is very welcome - we want to get  
> this right.
> I included a lot of folk, but not everyone here, on a renewed request to  
>  the IETF a little while ago  
> (  

yeah, i see my mail was a bit late to enter into consideration. that's
what i get for painting my apartment when i should be geeking.

> I'm hoping that's got all the right things in the right place. I've also  
> followed up on the discussion with IANA about rel="describedby"  
> (  
> which highlights to them that a) the @rel type registration is now in  
> the normative doc and b) that consensus around it has been reached (cue  
> massive calls of "I never said I agreed to that!!")
> I've requested application/powder+xml and application/powder-s+xml.

will you be available tomorrow to chat about powder-s+xml? after
geeking with Philippe Le Hegaret and Ralph Swick, we came to the
conclusion that +rdf+xml was worth a certain amount of fight (note
that the reasons for +xml also apply to rdf).

the prob was that we weren't convinced that POWDER-S should be
other than application/rdf+xml, so a chat might help. i have
telecons starting at 1500Z. (i wanted to spare ietf-types from
this discussion as i'm not sure how interested they'll be.)

> Stasinos - you have control of the formal doc just now - please see  
> Eric's comment below.
> Soon be Christmas...
> Phil.
> Eric Prud'hommeaux wrote:
>> Cc- while we work out what to ask for.
>> I kept Bjoern in the look 'cause he might be interested.
>> I've also added Ralph as he and I had a long POWDER-S media type discussion.
>> * Phil Archer <> [2008-12-03 10:49+0000]
>>> As for POWDER-S, the problem is the Semantic Extension   
>>> ( 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.
>> I think this argument calls for the creation of a media type for every
>> (non-XSD) DatatypeProperty, which leads to trouble when mixing them in
>> the same document. I, and I think the world, would be more motivated
>> by a protocol need for a media type for POWDER-S than by requirements
>> on the application interpreting the OWLRDF. For the latter, rdf+xml
>> struck Ralph and myself as sufficient and consistent with the expected
>> use of RDF and OWL.
>> Minor nit:
>> [[
>>   We extend RDF with the datatype properties ...
>> ]] —
>> would imply to me that the RDF machinery must be extended, as opposed
>> to the application interpreting the RDF graph. Maybe something like:
>> "POWDER-S uses an <a href="">OWL DatatypeProperty</a> to relate a resource to a regular expression which that resource matches. While POWDER-S uses OWL classes to group resources, any engine determining if a resource belonged in one of these OWL classes would need to be able to test a resource against a regular expression."
>> Keep going, brave soldier; some day we'll stop harassing you.
>>> Thanks
>>> Phil.
>>> Eric Prud'hommeaux wrote:
>>>> * Bjoern Hoehrmann <> [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]
>>>>> 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 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.
>>>> I propose that POWDER register application/powder+xml for POWDER, and
>>>> use application/rdf+xml for POWDER-S.
>>>> I think it's handy to include the media type registration in the spec,
>>>> à al .
>>>> Following , and
>>>> assuming you have no preference above being good netizens, I have
>>>> created a template for both (powder+xml and powder-s+xml) with
>>>> trumping
>>>> , 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:
>>>> 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 <>
>>>> 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.


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

Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Monday, 8 December 2008 20:21:31 UTC