Re: References Re: What are the requirements/problems? Re: Working on New Styles for W3C Specifications

-- 
Marcos Caceres


On Thursday, December 15, 2011 at 3:38 PM, Noah Mendelsohn wrote:

> 
> 
> On 12/15/2011 5:08 AM, Marcos Caceres wrote:
> > I agree. My working assumption is that all specs have bugs, but newer
> > versions fix old bugs but introduce new ones. Over time, updated specs
> > may have less bugs and eventually stabilise.
> 
> 
> 
> No, not foreseeable and avoidable ones. In many cases. Let's say that 
> specification S(V1) references Unicode(V1). Now unicode is updated. In many 
> cases it's crucial that users of S >not< start using that specification 
> with Unicode(V2) until the group responsible for S specifies a way of doing 
> so that's secure and interoperable. For that reason, it may be appropriate 
> for S(V1) to reference specifically Unicode(V1).
> 
> I should say I'm also a bit concerned about the tone of this discussion. I 
> respect your opinion on these things, Marcos, and it's possible that in 
> some of the cases where we disagree experience may prove you right. 
> Nonetheless, the tone of this interaction seems to be that you are setting 
> out potentially controversial points of view (e.g. of course forward 
> references to specs cause bugs...stuff happens), and are essentially 
> setting them up as the default position for discussion.


That's not my intention. I don't speak with authority, I'm only one individual and my opinions are just personal opinions - though yes, they are a little impassioned because I've been burnt a few times. Having said that, if I see something silly (e.g., locking XHTML to XML Ed. 4.), of course I'm going to call it out. 
 
> If you are serving 
> as de-fact editor for a redesign of W3C specification formats and 
> standards, then I think you should solicit opinions on questions like 
> biblio conventions in a more neutral way, and where possible, try to go 
> with the opinion that either commands consensus, or failing that, best 
> matches the full range of current practice. If you have suggestions, that's 
> great. Many of the decisions we've been discussing on this thread are 
> pretty subtle, involve difficult tradeoffs, and have been the subject of 
> long debate by some pretty experienced people for quite awhile. I'd prefer 
> we not come at them in a style of: "surely this is the answer, any 
> problems?" I'd much rather see a short list of options, with as clear a 
> listing as we can get of the pros and cons.

That's fair. I'll try to adapt and be more constructive and neutral.

Received on Friday, 16 December 2011 21:47:10 UTC