Re: Proposal for XSD data schema backward compatibility

The arguments I would give are:
1. The reason that no schemas have been produced up to now is that the format 
of the BDS has been so obscure and difficult to handle (I have seen at least 
one attempt by a very technically able person, which completely failed to 
understand the rules for creating the schemas)
2. Not only is it very difficult for people to create custom schemas, but it 
is also very difficult for this capability to be built into a policy editor, 
which of course would be the main driver for uptake.
3. If we want to encourage extensibility, the best way to do this is to use 
established standards.

On Fri 11 Jun 04 17:34, Lorrie Cranor wrote:
> Let me elaborate on the implications of this proposal... this breaks
> our backwards compatibility guidelines. This is an issue in the
> following cases:
>
> - Web sites that use P3P 1.0 custom schema (very few, the only one we
> could think of was ibm.com) will not have P3P policies that will be
> readable by P3P 1.1 user agents (unless those user agents voluntarily
> build in backwards compatibility).
>
> - Web sites that create P3P 1.1 policies with custom schema will not be
> readable by P3P 1.0 user agents that look at data elements (Privacy
> Bird, JRC, etc... this will probably not be a problem for IE6 or
> Netscape 7 because they don't appear to look at the data element level,
> but I could be wrong).
>
> I really don't like the idea of breaking backwards compatibility,
> however, these cases are rare enough that I'm not sure its a big deal.
> On the other hand, given how rare these cases are, we might argue its
> also not worth making this change... so I guess I'm still on the fence.
> The other alternative we discussed was providing a transform for the
> schema file itself from the new format back to the old. Giles felt this
> would be fairly difficult, although I don't think impossible, and it
> may be something Serge can help with.
>
> I guess I want to see laid out the arguments as to why it is
> advantageous to make this change so we can have a discussion about
> whether it is worth breaking backwards compatibility for it.
>
> Lorrie
>
> p.s Giles, please go ahead and add those items at the end to bugzilla
>
> On Jun 10, 2004, at 10:02 AM, Giles Hogben wrote:
> > Hi,
> > During the working group call yesterday, we came up with the following
> > proposal for integrating the new data schema format:
> > This was agreed among those present on the call, but we would like to
> > solicit
> > wider approval/disapproval. Please let me know if you think I
> > represented our
> > discussion accurately, and if you agree/disagree with the proposal.
> > Lorrie - I have included the other two small issues that I flagged up
> > in the
> > spec document.
> >
> > XSD Base Data Schema Backward compatibility proposal
> > -----------------------------------------------------------------------
> > --------
> >
> > 1. For policies using data elements from the P3P1.0 base data schema,
> > policies must be publised in the P3P 1.0 format. This may be acheived
> > however, but writing and validating the policy using the new schema
> > format
> > and then using the provided XSLT to transform back to the old format.
> > W3C can
> > provide such transforms as a service.
> > 2. Policy authors creating or using custom schemas MUST use the new
> > format.
> > They then have two options:
> > a. write the policy in the new format and transform back to the old
> > format -
> > the new elements will then not be validated by user agents (because the
> > schema will not be found)
> > b. write the policy in the new format and transform back to the old
> > format,
> > BUT include an EXTENSION element which provides the elements in a
> > format
> > which validates against the new schema they have written. User agents
> > implementing P3P1.1. must then validate such extensions (which can
> > easily be
> > done using a schema validator)
> >
> > I would also like to draw your attention to a question which I
> > included in
> > the new format specification (Lorrie, perhaps we can put it in
> > Bugzilla):
> > For the specification of  entity address data, XSD format following
> > the old
> > structure is somewhat cumbersome. because you end up with something
> > like:
> >
> > <user>
> >         <contact>
> >                 <postal>
> >                         <name>
> >                                 Entityname
> >                         </name>
> >                 </postal>
> >         </contact>
> > </user>
> >
> > <user>
> >         <contact>
> >                 <postal>
> >                         <city>
> >                                 Entitycity
> >                         </city>
> >                 </postal>
> >         </contact>
> > </user>
> >
> > <user>
> >         <contact>
> >                 <postal>
> >                         <street>
> >                                 Entitystreet
> >                         </street>
> >                 </postal>
> >         </contact>
> > </user>
> >
> > etc.....
> >
> > One suggestion from a colleague is to change the format to the more
> > efficient:
> >
> > <user>
> >         <contact>
> >                 <postal>
> >                         <name>
> >                                 Entityname
> >                         </name>
> >                         <city>
> >                                 Entitycity
> >                         </city>
> >                         <street>
> >                                 Entitystreet
> >                         </street>
> >                 </postal>
> >         </contact>
> > </user>
> >
> > Another issue for bugzilla is that the term name appears twice - once
> > for
> > business and once for the user - apparently with different semantics
> > (otherwise it would have been a data structure)-  but I would say it
> > should
> > only appear once.

Received on Monday, 14 June 2004 03:56:24 UTC