RE: Base Data Schema definition

No - if this relates to the thread below then the namespace we are talking
about is the namespace of the P3P1.1 base data schema which as Rigo says,
..../2002/01/BDSP3Pv1.1  doesn't make sense as it's now 2005.

Relating to your other questions however see below (maybe we're confusing
the 2),

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

****OK fine

>
>>> **
>>> **
>>> **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?

****I thought I'd seen it somewhere but now I can't find it. It never says
you can't assign categories to fixed elements and one example in the spec:

 <DATA ref="#user.login.password"/>
     <CATEGORIES><uniqueid/></CATEGORIES>
    </DATA>

Does this - although the point of this is not clear...

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

**** As it is now, you can apply optional at the data element level (below
data group) so I don't see the need to split.
The problem is that because the optional attribute is declared locally in
the 1.0 schema, it can't be declared by reference in the XSD base data
schema and has to be redefined in every custom schema.

>
>>> **
>>> **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?

**** I don't think there are any issues in terms of backward compatibility.
The issue is that it wouldn't have to be redefined in every custom schema.


Lorrie



>**-----Original Message-----
>**From: public-p3p-spec-request@w3.org 
>**[mailto:public-p3p-spec-request@w3.org] On Behalf Of Lorrie Cranor
>**Sent: 23 August 2005 15:14
>**To: Giles Hogben
>**Cc: 'Rigo Wenning'; 'public-p3p-spec'
>**Subject: Re: Base Data Schema definition
>**
>**
>**
>**OK, back up....
>**
>**So are you proposing that P3P1.1 P3P policies have a different name  
>**space than P3P 1.0 policies? If so, then that may be a 
>**problem, as we  
>**were trying to avoid introducing a new name space.
>**
>**Lorrie
>**
>**
>**On Aug 23, 2005, at 9:01 AM, Giles Hogben wrote:
>**
>**>
>**> No I'm not suggesting that. The import is of the P3P 1.0 schema not
>**> the
>**> P3P1.0 base data schema (which is not an XSD schema and therefore  
>**> can't be
>**> imported) because you need to use the yes/no attribute (and we  
>**> would like to
>**> use the optional attribute)
>**>
>**>
>**>> **-----Original Message-----
>**>> **From: public-p3p-spec-request@w3.org
>**>> **[mailto:public-p3p-spec-request@w3.org] On Behalf Of 
>**Lorrie Cranor
>**>> **Sent: 23 August 2005 14:54
>**>> **To: giles.hogben@jrc.it
>**>> **Cc: Rigo Wenning; 'public-p3p-spec'
>**>> **Subject: Re: Base Data Schema definition
>**>> **
>**>> **
>**>> **
>**>> **So Giles is proposing that the new P3P 1.1 base data 
>**schema import
>**>> **the old P3P 1.0 base data schema by reference? If so, 
>**then probably
>**>> **no reason to reproduce the 1.0 schema in 1.1. But maybe 
>**that is not
>**>> **what you are asking?
>**>> **
>**>> **Lorrie
>**>> **
>**>> **
>**>> **On Aug 23, 2005, at 4:00 AM, giles.hogben@jrc.it wrote:
>**>> **
>**>> **> xsd:import looks closed to me.
>**>> **> It validated so the syntax should  be OK.
>**>> **> Fine to change the namespace.
>**>> **>
>**>> **> Not sure I understand the last question. I would 
>**leave that up to
>**>> **> Lorrie.
>**>> **>
>**>> **>
>**>> **> ----- Original Message -----
>**>> **> From: Rigo Wenning <rigo@w3.org>
>**>> **> Date: Thursday, August 18, 2005 2:30 pm
>**>> **> Subject: Base Data Schema definition
>**>> **>
>**>> **>
>**>> **> Giles,
>**>> **>
>**>> **> in your new base data schema draft, you start like this:
>**>> **>
>**>> **> <xsd:schema
>**>> **>   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>**>> **>   xmlns="http://www.w3.org/2002/01/BDSP3Pv1.1"
>**>> **>   xmlns:p3p="http://www.w3.org/2002/01/P3Pv1"
>**>> **>   xmlns:p3pbds="http://www.w3.org/2002/01/BDSP3Pv1.1"
>**>> **>   elementFormDefault="qualified"
>**>> **>   targetNamespace="http://www.w3.org/2002/01/BDSP3Pv1.1">
>**>> **>      <xsd:import
>**>> **>       schemaLocation="http://www.w3.org/2002/01/P3Pv1.xsd"
>**>> **>       namespace="http://www.w3.org/2002/01/P3Pv1" />
>**>> **>
>**>> **> I think, the targetNamespace MUST be something different.
>**>> **It should
>**>> **> be a
>**>> **> new namespace. Suggestion is /2005/08/BDS-P3P11
>**>> **>
>**>> **> You fail to close <xsd:import>
>**>> **>
>**>> **> Does that mean, the old 1.0 Schema should be replaced 
>**in the Spec
>**>> **> as it
>**>> **> is already in the 1.0 REC and can be imported from there?
>**>> **Or should we
>**>> **> provide a combined XML Schema?
>**>> **>
>**>> **> Best,
>**>> **>
>**>> **> Rigo
>**>> **>
>**>> **
>**>> **
>**>>
>**>
>**>
>**>
>**>
>**
>**

Received on Tuesday, 23 August 2005 13:33:54 UTC