Re: Base Data Schema definition

Comments below.

On Aug 23, 2005, at 9:33 AM, Giles Hogben wrote:

> 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:

In 5.7.1 it says: "Please note that the category classes of fixed  
data elements/structures can not be overridden, for example by  
writing rules or policies that assign a different category to a known  
fixed base data element. User agents MUST ignore such categories and  
instead use the original category (or set of categories) listed in  
the schema definition."

I think that means you can't do that. I think "can not be overriden"  
means both that you can't assign a different category and that you  
can't assign a subset of the original categories (even though this is  
not spelled out).

>
>  <DATA ref="#user.login.password"/>
>      <CATEGORIES><uniqueid/></CATEGORIES>
>     </DATA>
>
> Does this - although the point of this is not clear...

I'm not sure why it does it either... could be an error. I'm guessing  
that a previous draft used dynamic.miscdata and that was later  
changed to the explicit data elements and the categories line wasn't  
deleted. I think we can fix that in 1.1.


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

OK

>
>
>>
>>
>>>> **
>>>> **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 15:50:40 UTC