W3C home > Mailing lists > Public > spec-prod@w3.org > October to December 2011

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

From: Marcos Caceres <w3c@marcosc.com>
Date: Sat, 24 Dec 2011 16:52:39 +0000
To: Noah Mendelsohn <nrm@arcanedomain.com>, fantasai <fantasai.lists@inkedblade.net>
Cc: liam@w3.org, "Martin J." <duerst@it.aoyama.ac.jp>, Jim Melton <jim.melton@oracle.com>, Bert Bos <bert@w3.org>, Julian Reschke <julian.reschke@gmx.de>, chairs@w3.org, "spec-prod@w3.org" <spec-prod@w3.org>
Message-ID: <3C28D2AA0E164EE8A5106607CE02211F@marcosc.com>


On Saturday, 24 December 2011 at 16:28, Noah Mendelsohn wrote:

> My concern here is only partly with the fixed policy that Marcos proposes,  
> but more fundamentally that I don't think this is the right place and time  
> to be having this debate.
>  
> As far as I know, what's really on the table here is an attempt to come up  
> with new formatting standards that will be more effective for readers and  
> other consumers than our previous TR formats, and to develop templates that  
> are more robust, easier to author, and easier to adapt when necessary.


Putting the references discussion aside, I have been arguing that that's only looking at half the problem. It's important to consider the primary users of the specs in the redesign process. The fact that these URLs (latest published draft, previous versions, editor's draft) are prominent at the very top in today's template means they need to be looked at and discussed.  

Also, we need to consider that most people are coming to specs through search engines: that actually does have a significant impact on which versions people view (hence the *BIG RED WARNING* in HTML5, which attempts to counteract what Google thinks is the right version for people to look at VS what the Editor thinks is version people should be looking at).     

(Apologies, I know we are going around in circles now so I'm going to stop and wait for an actual template to be put forward)
  
> I believe that changing or limiting conventions regarding the content or  
> wording of TR content should be out of scope, whatever the merits may be of  
> individual proposals. Stated differently, whatever format we come up with  
> should be adaptable for use with the full range of TR publications that  
> have been done by the W3C, except insofar as conventions they use may have  
> since been outlawed in W3C pubrules (and perhaps not even then, since it  
> would be nice to consider reformatting existing RECs with the new templates  
> whenever the next point releases come out). Trying to set policy while also  
> designing the format is a mistake IMO. I'd like to rule it out of scope.

My personal opinion is the opposite (though I agree there should be freedom for WGs to do whatever they want): I don't think design and policy can be divorced, though I'm sure aspects can be addressed incrementally (I think this will happen naturally through the design process because limitations with the policy will be encountered and we will have to work around those … again, HTML5's big red warning is an example of working around W3C policy limitation).   
> Rather, I'd like to see the team that does the template take a hard look at  
> the range of what's been published, with an eye toward creating a robust  
> and extensible framework. Almost every standard I've seen has had its own  
> unique requirements. To pick two examples that I'm familiar with: XSD  
> Structures [1] needed extensive markup and formatting support for it's  
> component structures, PSVI contributions, validation rules, etc.; the  
> Architecture of the World Wide Web [2] and many related TAG findings [3]  
> introduced highlighted "Constraints", "Principles" and "Good Practices".

Agreed. There are good things to take into consideration… for designers to provide design primitives (e.g., a nice box that can be coloured to suit "Constraints" or "Principles", etc. ) on which new things can be built.   
>  
> When findings were prepared, we had to fork XMLSPEC to create these (AWWW  
> was done directly in HTML, as I recall). Many recent Web Apps  
> specifications need specially formatted IDL, etc.

Right. I'm told that Respec.js provides a good adaptive architecture to handle this kind of growth. I'm not proposing the template use Respec.js (I personally prefer Anolis, for instance, I'm just saying that there places to look for ideas.   
> I think the number one threat to the adoption of any new template,  
> presuming it produces high quality output at all, will be failure to easily  
> adapt to such specialized needs.

Agree.   
> I'd rather see attention to those urgent  
> problems, rather than using this formatting exercise as an opportunity to  
> change the rules for what can or cannot be in a W3C biblio entry.

I think it is unfair to trivialise my request for a revision of the rules with the bibliographical entries. I don't raise the issue of process, versions, etc. because it's fun: I've seen serious commercial concequences in the Widget space from people implementing outdated versions to the detriment of the ecosystem (because they were commercially bound to do so). I also hear the counter arguments and can sympathise - just looking for a balance and to be heard.   
> Just make  
> sure the new biblios can handle all the entries we've needed during the  
> last 5 years or so, and we'll be fine. In particular, that will maximize  
> the likelihood that when minor changes are made to existing standards, the  
> new template can be considered.

Agreed.  

It would be great to actually hear from those that are working on the template. They've been a little too silent ;)  

Kind regards,
Marcos  
Received on Saturday, 24 December 2011 16:53:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:19:18 GMT