Re: New WD attached

>>> **3. Note that in section 3.3.8, I have removed reference to
>>> **the base attribute for DATA-GROUP. If we don't allow P3P1.0
>>> **base data schemas then this attribute no longer has any
>>> **meaning. I guess it should also be removed from the P3P
>>> **schema? Or should we leave it in just so as not to break P3P
>>> **1.0 policies?
>>>
>
> This needs a response from Lorrie.

My opinion is to leave it in the schema and in section 3.3.8 say that  
P3P 1.0 policies may use it but that it has been deprecated and has  
no meaning in P3P 1.1.

>
>>> **
>>> **
>>> **5. The original spec allows you to assign categories to
>>> **fixed elements so that if a fixed element has more than one
>>> **category, then you can specify it as being one of the 2. I
>>> **decided that this complicates the system too much and that
>>> **it would be simpler to remove this possibility - so the
>>> **fixed categories are just for rule matching and the dynamic
>>> **ones are for use within the policy. I hope this is in
>>> **agreement with the views of the WG.
>>>
>
> Again, this needs feedback from Lorrie.

Where does it say that?

>>> **
>>> **6. I wonder if we should remove the optional attribute from
>>> **individual datatypes and allow it only on DATA-GROUP - I
>>> **suppose that would break backward compatibility too much? It
>>> **does cause problems - see point 7.
>>> **
>>> **7. As it is now, custom schema writers are obliged to
>>> **include the datatype element + optional(yes/no) attribute as
>>> **the root element of their schemas. This is a bit messy
>>> **because among other things, the optional attribute is not in
>>> **the P3P namespace but in the namespace of the custom data
>>> **elements. I can't see an alternative to this because
>>> **otherwise we would have to include the datatype element in
>>> **the P3P schema and allow it arbitrary children, which would
>>> **break the validation functionality but if anyone has any
>>> **ideas... (it would be less ugly if they didn't also have to
>>> **add the optional(yes/no) attribute.).
>>>
>
> Both issues need further considerations. I can't solve them by editing
> the spec for the moment.
>

Real sites are using optional in their P3P policies and they are   
combining optional and non-optional in the same data groups. In order  
to avoid breaking backwards compatibility, a transform from P3P 1.0  
to P3P 1.1 would have to split statements so that the optional  
elements are in one statement and the non-optional ones were in  
another statement. This could be automated, but a human would still  
have to supply the relevant CONSEQUENCE element. This doesn't seem  
ideal. It would be good if we could find a way to keep the optional  
attribute attached to data elements.

>
>>> **
>>> **It would help if we could at least reference the optional
>>> **attribute in the P3P schema but at the moment it is declared
>>> **locally - if it were declared globally (which I don't think
>>> **would break backward compatibility), this would allow you to
>>> **write <xsd:attribute ref="p3p:optional" use="optional"/> in
>>> **the custom schema.
>>>
>
> Lorrie?

I'm not sure I fully understand the implications of a change from  
local to global. Is the issue that we would be changing the P3P XML  
Schema and thus would need a new namespace?


Lorrie

Received on Wednesday, 17 August 2005 02:04:31 UTC