proposal for versioning

Dear group,

Ref: <http://www.w3.org/2005/05/tr-versions>

Please find above some background on versioning practices at W3C. The 
issue is not determining major/minor version numbers for EARL but that 
there are cross-dependencies between different Technical Report (TR) 
documents. If we try to define EARL centrally in single place then we 
may simplify these relationships. Here is a suggestion:

# "EARL 1.0" consists of these parts:
- EARL 1.0 Schema, Recommendation of Day/Month/Year
- EARL 1.0 Guide, WG Note of Day/Month/Year
- HTTP-in-RDF, WG Note of Day/Month/Year
- Content-in-RDF, WG Note of Day/Month/Year
- Pointers-in-RDF, WG Note of Day/Month/Year

This definition for EARL 1.0 is to be recorded in the conformance 
section of EARL 1.0 Schema, which is the core definition for EARL.

Now, over time, one or more of these documents may need to change. For 
instance, let's assume that a new HTTP version is released (HTTP 1.2), 
and we want to update HTTP-in-RDF accordingly. We would end up with the 
new "HTTP-in-RDF, WG Note of Day2/Month2/Year2". The fact that there is 
this new version of HTTP-in-RDF does not change the definition of what 
"EARL 1.0" is, as long as we define EARL 1.0 using a specific version 
(by date or otherwise) of HTTP-in-RDF (see the definition above).

At some stage we will want EARL tools to adopt this new HTTP version, 
which means that we would need to update EARL as a whole. For this 
particular example, we would probably want to create "EARL 1.1" which 
supersedes "EARL 1.0", and includes the new HTTP-in-RDF specification. 
We would need to update the Schema document to at least adopt the new 
definition of EARL by pointing to the new HTTP-in-RDF specification:

# "EARL 1.1" would (hypothetically) consist of these parts:
- EARL 1.1 Schema, Recommendation of Day3/Month3/Year3
- EARL 1.1 Guide, WG Note of Day3/Month3/Year3
- HTTP-in-RDF, WG Note of Day2/Month2/Year2
- Content-in-RDF, WG Note of Day/Month/Year
- Pointers-in-RDF, WG Note of Day/Month/Year

Note that the Guide always changes along with the Schema document, as 
they are defined as companion documents. Also, since the Schema is a 
REC-track document, we will need to go through the development stages, 
produce test suites, and demonstrate implementations. This all makes 
sense if we want to have a stable "EARL 1.1".

Finally, we can still think of using version numbers for HTTP-in-RDF, 
Content-in-RDF, and Pointers-in-RDF. This is a separate issue if we 
define EARL in its Schema document.


Best,
   Shadi

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/ |
   WAI International Program Office Activity Lead   |
  W3C Evaluation & Repair Tools Working Group Chair |

Received on Wednesday, 24 June 2009 09:52:27 UTC