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 09:38:09 UTC