W3C home > Mailing lists > Public > public-p3p-spec@w3.org > August 2005

Re: New WD attached

From: Rigo Wenning <rigo@w3.org>
Date: Tue, 16 Aug 2005 21:23:23 +0200
To: Giles Hogben <giles.hogben@jrc.it>
Cc: "'Lorrie Cranor'" <lorrie@cs.cmu.edu>, "'public-p3p-spec'" <public-p3p-spec@w3.org>
Message-Id: <200508162123.24856.rigo@w3.org>
Am Tuesday 02 August 2005 16:33 verlautbarte Giles Hogben :
> Sorry I used the wrong base data schema source file so use these
> attached files...
> >**-----Original Message-----
> >**From: Giles Hogben [mailto:giles.hogben@jrc.it]
> >**Sent: 02 August 2005 16:16
> >**To: 'Rigo Wenning'; 'Lorrie Cranor'; 'public-p3p-spec'
> >**Subject: New WD attached
> >**
> >**
> >**Hi Rigo,
> >**I attached a new working draft (saved in unicode for your
> >**benefit) with the changes to the Data schema included. 

Actually, the attachment was binary and I had to make several iterations 
to get to the real draft. Additionally, you took the Draft from May 
2005 instead of taking the one form July. It took me 440 deltas to get 
a clean version, but now it is done ;)

> >There 
> >**are a few important points to note (the most important to
> >**resolve is 7.) Please note that predictably there were also
> >**some changes to the transforms and the xsd schema as a
> >**result of updating the spec - so please use the attached as
> >**the latest version. I haven't updated the schema in the spec.

Will do and integrate..
> >**
> >**
> >**1. Still to do (could you or Thomas take care?) is the EBNF.
> >**Note, EBNF must also be updated also for ENTITY element and
> >**section 3.3.8

I will take care of it, but I'm unsure about the whole integration. I 
will try to find out ASAP
> >**
> >**2. Please put in and check the references to the XSLT's
> >**(attached again for your convenience) and checking other
> >**anchors and links

I will transform those into HTML and link them in the Spec. But I'm 
unsure, whether I should provide them as separate files or integrate 
them as annexes 

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

> >**
> >**4. Some of the indentation in the examples needs cleaning
> >**up. I figured it was a waste of time for me to do it because
> >**you probably have a tool to do it automatically.

You also made some typos. I cleaned them already in the current 
> >**
> >**
> >**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.

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

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

> >**
> >**8. For categories (in base data schema and transforms) I
> >**have referred to the P3P 1.0 namespace but should this be
> >**changed once we know the P3P1.1 namespace?

This depends. For elements of the P3P 1.0 dataschema, we'll need the old 
namespace for backwards compatibility. But for anything new, we need a 
new namespace. I would have to update the P3P 1.1 Schema and perhaps 
use a new namespace.



Received on Tuesday, 16 August 2005 19:23:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:19 UTC