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

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