- From: Dennis E. Hamilton <dennis.hamilton@acm.org>
- Date: Thu, 16 Oct 2003 21:01:38 -0700
- To: "Eric Sedlar" <eric.sedlar@oracle.com>, "Julian Reschke" <julian.reschke@gmx.de>, "Stanley Guan" <stanley.guan@oracle.com>, <w3c-dist-auth@w3.org>
I don't understand how we got to this point. What about this has anything to do with breaking clients? I thought the "ignore any element/attribute you don't understand" was a pretty clean rule, and trumped the use of extensions *in*the*DAV*XML* by another participant in the protocol. And this goes along with knowing that a service may also ignore XML elements and attributes from you that it doesn't understand for the level of DAV that it implements. The rules to DAV seem pretty clear: new DAV specs that come out can add elements to the DAV namespace. What an older DAV implementation is to do with any of that sent its way is well defined. Any use of a schema validator would have to allow for that. But I might know that what I am producing (not receiving) is at a particular level of DAV, and I use schema assessment to verify that. And if there is an update to DAV, I might have to update the schema I am using. Or not, if I don't intend to use the extension and the rules say it is still legal to ignore the extension. Where does breaking come in? I apologize Eric, I don't know what the context is any more. -- Dennis -----Original Message----- From: Eric Sedlar [mailto:eric.sedlar@oracle.com] Sent: Thursday, October 16, 2003 15:34 To: dennis.hamilton@acm.org; Julian Reschke; Stanley Guan; w3c-dist-auth@w3.org Subject: Re: DAV Schema Assessment (was Re: rfc2518bis DAV DTD ...) Dennis-- The issue is not that "anyone can invent an element", but that new DAV specs will come out, and would break older clients not updated with the new schema. The issue is that XML Schema would constrain the DAV WG's ability to extend the specification. --Eric [ ... ]
Received on Friday, 17 October 2003 00:04:47 UTC