Re: Proposal for XSD data schema backward compatibility

If we had this tool, it would be great. I am dubious that it is 
possible without ridiculous amounts of effort.
I think if there were a policy editor that could create custom 
schemas, people would make them. Perhaps this is something we might 
integrate into the one we are building.

----- Original Message -----
From: Lorrie Cranor <lorrie+@cs.cmu.edu>
Date: Monday, June 14, 2004 3:36 pm
Subject: Re: Proposal for XSD data schema backward compatibility

> So this argument suggests that if we had a tool that could 
> translate  
> from new to old schema format then we could keep the old format in 
> the  
> spec but produce a note or appendix explaining the new format and  
> suggest that schema designers and tool makers use the new format 
> and  
> then translate back to the old format. This would make it easy for 
> 
> people to create new schemas if they want to, and would not impact 
> 
> backwards compatibility.
> 
> Personally, while I agree that the old format is difficult, I am  
> doubtful that it is the reason we haven't seen custom schemas. I 
> think  
> there just hasn't been much of a demand for them. Most sites would 
> 
> rather just declare data categories than try to declare their data 
> on  
> such a fine grained level. This may change as new products become  
> available that track data on the back end.
> 
> Lorrie
> 
> 
> 
> On Jun 14, 2004, at 3:55 AM, Giles Hogben wrote:
> 
> > 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 16:56:08 UTC