- From: Lorrie Cranor <lorrie+@cs.cmu.edu>
- Date: Tue, 23 Aug 2005 11:49:45 -0400
- To: Giles Hogben <giles.hogben@jrc.it>
- Cc: "'Rigo Wenning'" <rigo@w3.org>, "'public-p3p-spec'" <public-p3p-spec@w3.org>
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