W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

Re: Formulate erratum text on versioning for the web architecture document

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 17 Feb 2009 18:59:31 -0500
To: John Kemp <john.kemp@nokia.com>
Cc: Larry Masinter <masinter@adobe.com>, David Orchard <orchard@pacificspirit.com>, "www-tag@w3.org WG" <www-tag@w3.org>, www-tag-request@w3.org
Message-ID: <OFFD9C257C.2260CFE0-ON85257560.0082C323-85257560.00838677@lotus.com>
John Kemp writes:

> Section 4.2 on versioning and extensibility thus seems intended to 
> relate specifically to "data format specifications" and to a specified 
> agreement regarding representation data.
> 
> As such, I don't feel that this text casts aspersions on languages 
> such as PHP (which as far as I know has no language specification) or 
> Java. I am not sure that they have the same needs with respect to 
> "agreement on the correct interpretation of representation data". I do 
> find your comments, however, to be instructive. I'm just not sure how 
> to best use them yet in this specific case.

You're right that AWWW applies more obviously to data formats.  Used 
programming languages as an example just because they're so widely known. 
I think that my blog posting makes clear that the tradeoffs and concerns 
apply equally to data format specifications.  For example, I believe that 
the version identifier in XML proved more of a hindrance than a help to 
adoption of XML 1.1.

> Are you saying that a new version identifier should not always be 
> minted just because a new version of the language has been? That at 
> least is the intent I had in writing the additional best practice text.
> 
> But I would like to separate the idea of creating a mechanism for 
> allowing version indications, from the practice of assigning and 
> using new version indicators.

You seem to be suggesting that specifications should assign identifiers to 
successive variants of a language, regardless of whether those identifiers 
are to appear in instances.  Maybe that's a good thing in general, e.g. so 
people can discuss one version or another, or maybe it's something to do 
on a case by case basis.  Still, the particular AWWW text we're discussing 
says:

        Good practice: Version information

        A data format specification SHOULD
        provide for version information.

I read that as intending to say that it should provide for version 
information in the instance documents, and that's what I feel is clearly 
not always true.  Accordingly, I would like to see this replaced with 
advice that is more along the lines of what was in my previous email.  I 
believe that including such a revision in the AWWW errata document [1] 
would be a good step. 

Perhaps you're reading the above Good Practice Note (GPN) as not talking 
about the instance at all, but just the specification?   In that case, I 
think it should be clarified. I'm fairly sure that the >intention< was to 
recommend version fields in the instances, but I believe this part of AWWW 
was "baked" before my time on the TAG.

Thank you.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








John Kemp <john.kemp@nokia.com>
Sent by: www-tag-request@w3.org
02/17/2009 05:22 PM
 
        To:     "ext noah_mendelsohn@us.ibm.com" 
<noah_mendelsohn@us.ibm.com>
        cc:     David Orchard <orchard@pacificspirit.com>, Larry Masinter 
<masinter@adobe.com>, "www-tag@w3.org WG" <www-tag@w3.org>
        Subject:        Re: Formulate erratum text on versioning for the 
web architecture document


Hello Noah,

Thanks very much for the comments. Addressing only the current action 
for now. More on the general issue later:

On Feb 17, 2009, at 4:42 PM, ext noah_mendelsohn@us.ibm.com wrote:

> John proposes:
>
>> I believe that the best practice is still correct and important - 
>> data
>> format specifications should provide a mechanism (where that 
>> mechanism
>> might simply be "use XML namespaces") allowing instances to indicate
>> version information. Authors will likely not know whether they will
>> later have to create a new, incompatible version of a format a 
>> priori,
>> but should likely assume that they will.
>
> Well, I still respectfully disagree.  This suggests that a big 
> subset of
> the programming languages we use are poorly designed because they 
> don't
> invite us to say things like:
>
>        <?php PHPVersion="4.1"  ...  ?>
>
> or to put Java version="2.0"  in our Java source files.

I was addressing specifically the documentation produced in AWWW 
Section 4 [1], which states:

> "A data format specification (for example, for XHTML, RDF/XML, SMIL, 
> XLink, CSS, and PNG) embodies an agreement on the correct 
> interpretation of representation data."

Section 4.2 on versioning and extensibility thus seems intended to 
relate specifically to "data format specifications" and to a specified 
agreement regarding representation data.

As such, I don't feel that this text casts aspersions on languages 
such as PHP (which as far as I know has no language specification) or 
Java. I am not sure that they have the same needs with respect to 
"agreement on the correct interpretation of representation data". I do 
find your comments, however, to be instructive. I'm just not sure how 
to best use them yet in this specific case.

>  I gave my reasons
> in the blog posting, and I won't repeat them here.
>
>> I would suggest, however, that perhaps an additional best practice
>> might be warranted, along the lines of Noah's suggestion in [3]:
>>
>> "If a language, or data format, changes in incompatible ways, a new
>> version identifier should be assigned to the updated data format, and
>> allowed in document instances."
>
> Thank you.  I do think that bit is worth saying.  Overall, I might 
> go with
> something like this:
>
> "In cases where the same instance document has incompatible meanings 
> per
> two or more versions of the language specification, provision MUST 
> be made
> for indicating the version(s) used to encode each instance.  Use of
> explicit version identifiers in other languages is optional, and in 
> some
> cases such explict identifiers can actually inhibit the adoption of 
> new
> language versions, or can inhibit interoperability between systems
> implementing differing versions of the language."

Are you saying that a new version identifier should not always be 
minted just because a new version of the language has been? That at 
least is the intent I had in writing the additional best practice text.

But I would like to separate the idea of creating a mechanism for 
allowing version indications, from the practice of assigning and using 
new version indicators.

>
> ...or words to that effect.
>
> As an example of that last admonition, one can argue that XML 1.1 
> might
> have been deployed much more successfully if no version attribute were
> provided in the XML declaration.

The point I have been trying to make is that this issue doesn't seem 
to be about whether a version attribute is _provided_ in the format 
specification; it is about whether a new version identifier is created 
when a new version of a language is created.

>  I don't believe it's the case that the
> same document ever had two different legal meanings in XML 1.0 and XML
> 1.1;  it's just that some documents are legal in one version and some
> legal in the other.  XML 1.0 processors would have rejected content 
> using
> new XML 1.1 characters just as surely (if not just as early) if no 
> version
> identifier were provided.  The ID is really just a cross check or 
> early
> warning in such cases.  The only time it's really crucial is if the 
> same
> document can mean different things as the specification changes.

I don't think this is a problem caused merely by the existence of a 
'version' attribute.

Regards,

- johnk

[1] http://www.w3.org/TR/webarch/#formats
Received on Wednesday, 18 February 2009 00:09:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:12 GMT