Re: P3P: General Comments

Sean B. Palmer <sean@mysterylights.com> wrote:

>> 2.2.3 The HTML link Tag [...]
>> <link rel="P3Pv1"
>>     href="http://catalog.example.com/P3P/PolicyReferences.xml">
> 
> Error: this link form is illegal in HTML 4.01 onwards; list of link
> types is clearly enumerated [1] in HTML 4.01, and "P3Pv1" isn't in
> there. The only way to extend the list of link types is to point to a
> metadata profile by setting the "profile" attribute on the <head>
> element. I suggest you simply define the namespace for P3P as being a
> metadata profile in (X)HTML and use that, so that the code becomes:-

Err, this is not necessary -- the spec says:

    Authors may wish to define additional link types not described in this
    specification. If they do so, they should use a profile to cite the
    conventions used to define the link types. Please see the profile
    attribute of the HEAD element for more details.

Note the use of SHOULD, not MUST.

>> 3. Policy Syntax and Semantics
>> P3P policies are encoded in XML. They may also be represented
>> using the RDF data model ([RDF]); however, an RDF representation
>> is not included in this specification. (Such a representation is
>> planned to be made available as a W3C Note prior to submitting P3P
>> as a Proposed Recommendation, together with a suitable RDF
>> encoding of the policy reference file).
> 
> I haven't yet been able to find any public justification for using a
> flat XML model to represent the P3P system over RDF (maybe I'm not
> looking hard enough; if there is one, please accept my apologies).
> Submitting it as a note afterwards implies that it won't be a part of
> the recommendation as it stands, and hence any implementations thereof
> will be proprietary. Because the RDF data model is such a precise and
> repurposable model, I have to wonder why you didn't use this in the
> first place, although the two most likely reasons that come to mind
> are 1) simplicity, and 2) trouble in representing the datatypes. Both
> of these are fair points, but you might want to look into some of the
> DAML [2] work on datatypes and structuring, especially the 2001 March
> version [3].
> 
> Of course, I would raise this point, because I'm an RDF developer :-)

Certainly, looking at the spec it seems like only one or two changes would
be needed to make it RDF-compatible. I'd be happy to provide assistance with
this if necessary.

> 2.3.2.1.2 Wildcards in policy reference files
> 
> Policy reference files make statements about what policy applies to a given
> URI. Policy reference files support a simple wildcard character to allow
> making statements about regions of URI-space. The character asterix ("*") is
> used to represent a sequence of 0 or more of any character. No other special
> characters (such are those found in regular expressions) are supported. Note
> that since the asterix is also a legal character in URIs ([URI]), some special
> conventions have to be followed when encoding such "extended URIs" in a policy
> reference file: 

This portion of the spec seems to be sort of difficult to implement. The
code to decode some characters but not the asterisk, etc. seems difficult
and prone to confusion. You may wish to consider appendix C of the URIspace
proposal which shows an RDF-compatible way of doing this:

http://www.w3.org/TR/URIspace

Oh, and it's spelled asterisk.

-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Received on Sunday, 13 May 2001 14:22:07 UTC