Topic for 4-jan: shortnames for publication

WebCGM WG --

There is a proposal that we need to discuss and dispose (approve or 
disapprove) that affects the cover page of the W3C specification, and the 
shortname that we have used for WebCGM 2.0 (as in .../TR/webcgm20/", or as 
in .../PR-webcgm20-20061017/).

In a recent thread [1],
[1]  http://lists.w3.org/Archives/Public/public-webcgm-wg/2006Dec/0000.html ,
the question was raised and we discussed whether the 2.0 specification 
"supersedes" the 1.0 specification.  We concluded that it does not.


In a more recent thread [2],
[2] http://lists.w3.org/Archives/Public/public-webcgm-wg/2007Jan/0002 ,
Ian Jacobs (Comm) raised the proposal:

>Meanwhile, I would like to talk to the WG about using several
>latest version URIs in the Recommendation, following this guidance [1].
>Specially, I propose these "latest version" URIs:
>http://www.w3.org/TR/webcgm/ -> Most advanced Web CGM Recommendation
>http://www.w3.org/TR/webcgm1/ -> Latest Web CGM 1.x
>http://www.w3.org/TR/webcgm2/ -> Latest Web CGM 2.x
>Thus, when Web CGM 2.0 is published as a Recommendation, it would
>include two latest version URIs: (the first and third above). Should
>there ever be Web CGM 3, we would update /TR/webcgm to point to that
>Recommendation. This would allow readers of the Web CGM 2.x
>Recommendation to find the newer Web CGM 3 without our having to
>republish any specifications.

Ian and I have talked to clarify my understanding.  Here is what it would 
mean in practice for the W3C Recommendation:

PROPOSAL:
==========

1) Status section (on cover page) should explain relation of this spec to 1.0

2) Top of Recommendation should include two latest version URIs (webcgm2, 
webcgm shortnames), along the lines of how MathML [3] has done it:
[3] http://www.w3.org/TR/MathML2/

3) W3C webmaster will redirect /TR/webcgm20 -> /TR/webcgm2 forever.

4)  TR page will only list WebCGM 2.0 title/URI; people will learn about 
2.0/1.0 relationship by reading 2.0 status section.

5) Documents always remain available at "this version" URIs, so the 
documents will not disappear.

More about #1:
----------
In the SoTD of the cover page, we would add something like:

WebCGM 1.0 functionality is mostly a subset of WebCGM 2.0 functionality, 
with a few exceptions (e.g., feature deprecation) as described in this 
WebCGM 2.0 text.  Unless there are application-dependent 1.0 legacy 
constraints, existing WebCGM applications are encouraged to migrate to 
WebCGM 2.0.  WebCGM applications that need DOM and XCF functionality must 
use WebCGM 2.0.  New WebCGM applications are encouraged to use WebCGM 2.0, 
and in the absence of 1.0 legacy constraints, WebCGM authors are encouraged 
to generate 2.0 content.

More about #2:
----------
Instead of the single "Latest version" [4] such as you see at the current 
PR text ([4] maps to [5] at this point in time)...

[4] http://www.w3.org/TR/webcgm20/
[5] http://www.w3.org/TR/2006/PR-webcgm20-20061017/

...you would see:

Latest WebCGM 2 version:
http://www.w3.org/TR/webcgm2/
Latest WebCGM Recommendation:
http://www.w3.org/TR/webcgm/

More about the webcgm2 shortname:
----------
Note that it is proposed to change "webcgm20" to "webcgm2".  So any future 
WebCGM 2.1 would be found by the webcgm2 shortname, e.g., the "Latest 
WebCGM 2 version" URI above.  But it would not find WebCGM 3.0, if there is 
such in the future.  (However, /TR/webcgm/ *would* find it.)

Where would REC WebCGM 2.0 be?
----------
[6] http://www.w3.org/TR/2006/PR-webcgm2-20070130/

ISSUES:
==========

a.) it requires "director approval" to change a shortname.  Ian estimates 
that Steve would approve it routinely, as we are trying to align with 
conventions that Comm is evolving.

b.) Slightly different than how OASIS organizes it.  Right now, the text 
that was voted on for the OS ballot is the 2nd CS text [7], at:
[7] http://docs.oasis-open.org/webcgm/v2.0/CS2/webcgm-v2.0-index.html .
So we can imagine that the OS text would be at:
[8] http://docs.oasis-open.org/webcgm/v2.0/OS/webcgm-v2.0-index.html
You can imagine what the URIs would be for 2.1, 3.0, etc.  I don't see this 
as a disadvantage, but rather an inevitable consequence of the different 
conventions of the two organizations.  We would ensure that corresponding 
major versions (2.0, 3.0, etc) and minor versions (2.1) cross link properly 
to their counterparts.

CONCLUSION:
==========
We have apparently gotten away with a violation of pubrules, in that our 
SoTD does not set expectations about 2.0 versus 1.0, so we need to  pay 
attention to item #1 of the PROPOSAL.  Other than that, this is not 
absolutely required, but is a suggestion of Ian's to align better with 
current W3C conventions.

We have the option to request, "thanks, but too late, can we stick with 
what we have now?".  Or to make adjustments like, "we'd like to use 
shortname "webcgm20" instead of the proposed "webcgm2", because webcgm20 
aligns better with other organizations' usages".  Or to accept the PROPOSAL 
as is.

Thoughts?  Questions?

Regards,
-Lofton.