- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Sat, 24 Dec 2011 11:28:01 -0500
- To: Marcos Caceres <w3c@marcosc.com>
- 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>
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. 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. 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". 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. 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. 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. 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. Thank you. Noah [1] http://www.w3.org/TR/xmlschema11-1/ [2] http://www.w3.org/TR/webarch/ [3] http://www.w3.org/2001/tag/findings On 12/24/2011 5:37 AM, Marcos Caceres wrote: > > > > On Saturday, 24 December 2011 at 04:16, Liam R E Quin wrote: > >> On Fri, 2011-12-23 at 18:41 +0000, Marcos Caceres wrote: >> [...] >>> As an example, there is no guarantee that "xmldig-core1" will >>> eventually (when it goes to Rec) replace "xmldig-core". I would like >>> that guarantee. >> >> >> >> You can't have it. >> >> Sometimes the new spec supplants the old and sometimes not. > > But for cases where it does not break backwards compatibility, then I should be able to have it. It's the same with namespaces: you don't version namespaces (that would be stupid): you only mint a new one in the extreme case where you break backwards compat. > > Groups like XML Dig Sig acknowledge that in their spec [1]: > > "No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace." > > So why not do the same for specs? > >> For example, sometimes we publish a spec and the community by and large >> rejects it; XML 1.1 was an example. > > That's a good example actually. Except, it generally excepted that XML 1.1 is no backwards compatible with 1.0, hence: > > <?xml version="1.1"?> is explicitly needed to trigger it. > > So that would go into it's own short name (xml11), as it currently does. >> We have to deal with the world as it is, not with the world as we'd like >> it to be :-) > > The w3c isn't the world: we made the w3c that way, which means that we can change it. > > Please, lets keep a "can do" attitude ;) > > [1] http://www.w3.org/TR/xmldsig-core/#sec-Versions >
Received on Saturday, 24 December 2011 16:28:41 UTC