Re: [BH] The most generic binding

On Wed, Jul 16, 2003 at 11:55:17AM -0400, Joseph M. Reagle Jr. wrote:
> Ah, ok, though it seems to be complicate things for reasons I don't quite 
> understand yet. Some questions/issues:

I don't know if it complicates things as it removes the whole overhead
of referencing and integrates into the natural way of writing down XML.

> 1. What is the benefit of splitting the policies out across these sections 
> over the existing mechanism of having different DATA elements in different 
> POLICY elements within a POLICIES?

See your mail to Lorrie: You seem to assume a binding between an
XPointer and a P3P Data-Element. This binding does not exist now. In
fact, that is the second solution Lorrie mentioned in the call today: 

Extending the PRF to allow XPointer - Statements and bind a specific
policy to a specific node-set in the XML-Document. This needs a second
document to be written. This adds overhead as you still need a binding
mechanism while an attribute would have an implicit binding of the
policy by the element it sits on.

E.g. your XForms engine would have to implement XPointer for that reason
while the direct attribute would only trigger the simple parsing of that
new attribute which is then delivered to the P3P engine.

So my arguments are:
It is easier to write
It is more intuitive
It is easier to implement

> 2. In your example, this means that the XML application schema will have to 
> permit these foreign P3P elements, which prexisting XML formats won't be 
> able to accomodate, and all such future ones would have to take this into 
> account for, which I think unlikely.

This is ignoring the fact that we are already mixing namespaces today,
if the mixing is well defined. So the XML application schema does not
have to accomodate, but the application must be aware of this generally
available attribute that we have specified in some specification. This
at least what Steven Pemberton suggested. Other Specifications, he said,
could just use this short specification and kind of 'import' it. 

So the scope of this is not only addressing P3P 1.0 and Web Services but
also all kinds of future dependencies of e.g. Device Independence
Specifications.

> 
> I do believe that in the future once we have the P3P data structures in 
> standard XML/schema, it will probably make sense to reconsider the design 
> of P3P with all of the stuff, but in the medium term P3P 1.0 gives you the 
> granularity in the policy, and the XForms proposal gives us a way to map a 
> form element with a DATA ref that one will find in the POLICY, right?

Giles has already written a XSLT-transform to transform P3P data schemas
into XML Schema. So this can be transformed already on the fly. But the
granularity you are claiming is simply not there, as the binding
mechanism is not there. So we have three possibilities:

1/ Stick with the existing binding and require a URI for everything, not
allowing to address sub-parts of a document (e.g. XForms form-fields)

2/ Add a complicated binding mechanism a la XPointer/XPAth to the Policy 
Reference File allowing to address a certain nodeset of an existing XML
Document (which still needs to have a URI)

3/ Have an elegant way of implicitly binding a P3P Policy to an
arbitrary XML Element as an addition to the things already under 
way in [1]. This attribute would carry it's own namespace. Applications
that are P3P - aware can just use it out of the box by implementing the
desired behaviour. (binding)

  1. http://www.w3.org/P3P/2003/p3p-beyond-http/Overview.html

Best,
-- 
Rigo Wenning            W3C/ERCIM
Policy Analyst          Privacy Activity Lead
mail:rigo@w3.org        2004, Routes des Lucioles
http://www.w3.org/      F-06902 Sophia Antipolis

Received on Wednesday, 16 July 2003 13:50:34 UTC