RE: Partial Review of http://www.w3.org/2001/tag/doc/versioning-20070326.html

Stuart, 

I have processed your comments.  I've called out comments where I didn't
do roughly what you suggested, otherwise I did something to the document
to address every other comment.  I still have more work to do on the
document before posting an update, then you can take a look at the
update and see if what I've done is ok.  

>>"Is that two individual texts that just happen to overlap - or is that
the entire set of texts are at least in a subset relationship if  not
identical  -ie. have the same extension (enumeration of members)"

I think it isn't that they just happen to overlap, though they may.
Imagine our name language had defined first and last instead of given
and family.  Some cultures have first=given and last=family, and others
have first=family and last=given.  Texts are the same but information is
different.

>>" backward compatibility means that a consumer of a newer language
version can be rolled out in a way that systems continue to operate in
the presence of producers of the older language version." I don't see
that rolling out a consumer of the new language version could "break" a
producer of the old language version - however I do see that systems
build around both could fail if the language change were not backward
compatible."

I don't understand the objection.  I'm saying that a new consumer could
break an older producer if the change isn't backwards compatible, and
you are talking about systems built around both could fail.  In your
"system", the consumer would throw an error and "break" the producer.

>>"Forward and Backward compatible change both seem desirable -
particular since communication is typically not unidirectional. A
forward and backward compatible change in a language suggest that it is
impossible to make change. OTOH if the texts can be partitioned by
'direction' such that a one party, changes to inbound texts are
"backward compatible" and changes to outbound texts are forward
compatible - there is some hope of updating peers of that kind ahead of
its 'complement'."

I quite agree.  I've made the point regularly that any bidirectional
communication, say with a Web service, means that if one sides, it may
want to be backwards AND forwards compatible with older clients.  Older
clients will send texts under the original language, but those clients
could receive texts under the newer language as a response.  And vice
versa, there could be a newer client.  I touched on this briefly in the
mention of Web services with compatibility definitions.  I think a bit
more treatment is deserved.  I've added an ednote.

>>"I think that we need to more carefully highlight when we are using
compatibility as a relation between language definitions and when we are
using it as a relation between a language defn and a consumer/producer
agent. (or try to normalise things so that we only speak of
compatibility between language defns)."

I've removed the sentences around producers that produced defined text
set only vs accept text set.  I still think there's something there
because a producer may only produce defined texts which would has an
"easier" compatibility guarantee than a producer that produces accept
texts.

>>"Is this not this second clause implict in the superset relation and
therefore redundant"

I don't think so, because the first clause only says superset/subset, it
doesn't say about whether the information is compatible or not.

>>You incorrectly changed the 2nd bullet from Accept Text set to Defined
Text set, in "Language L1 is strictly forwards compatible with Language
L2 if L1 Accept Text set > (superset) Language L2 Accept Text set AND
every text in L2 Accept Text set is compatible with L1.".

These have to be Accept Text set because L1 has to accept everything
that is possible by L2.

>>"Oh that is just too simplistic. Taken literally that says that a text
of the Name Language is a text of the PO language - whereas it is more
of a convolution where texts from the Name language are embedded within
the PO language."

I don't think it says that.. But I've tried to reword that para.

>>"Surely, in pratice, L1' is infact the earlier language is large
accept set arises because of an open extensibility point which L1 at
least partially closes through the definition of some extension."

In this case, L1' is the later language.  The size of the accept set has
nothing to do with "time" of the language.  However you are absolutely
right that a language that defines an extension will partially close the
Accept Text set.  This is why there has to be the point about full vs
strict compatibility.  A producer that produces an extension that is not
in a languages Accept Text set will be incompatible.  I'm still
struggling with how to deal with the need to talk about producers
producing just Defined Text set items or Accept Text set items.

>>"This probably needs work. There is no defn of a "least partial
language".... And presumable the least amount of 'understanding' is none
at all... "

That is true but not helpful.  If you define a partial language that has
nothing, then you gain no information so what's the point?  I've added a
bit of text below to say "The flavor of a language that implies the
smallest amount of understanding, which is the smallest Defined Text
set, will be also be the most liberal and have the largest possible
Accept set."

Cheers,
Dave

> -----Original Message-----
> From: Williams, Stuart (HP Labs, Bristol) [mailto:skw@hp.com] 
> Sent: Monday, May 21, 2007 7:12 AM
> To: David Orchard
> Cc: www-tag@w3.org
> Subject: Partial Review of 
> http://www.w3.org/2001/tag/doc/versioning-20070326.html
> 
> Dave and TAG,
> 
> In preparing for our forthcoming F2F I have reviewed about 
> the first half of the 26th March 2007 version of the draft 
> part 1 versioning finding [1] and placed annotated copies in 
> www-archive@w3.org at[2,3] (.html and .doc respectively). 
> Although three drafts have just been published[4] to replace 
> the previous two, the comments in this review may still be 
> relevant to the revised part 1 [5], so I'm making them 
> available for discussion (apologies that I've ended up using 
> a word processor to annotate the text - I am still looking 
> for good tools for annotating review copy - any suggestion 
> for something more HTML oriented).
> 
> I like the division of the part 1 finding into two parts, 
> "terminology"
> [5], which can act as a reference for the other parts, and 
> strategies [6].
> 
> One of my concerns is how the TAG achieving concensus on this 
> work. As others have previously remarked, for any given 
> document one only has a limited number of good reviews before 
> becoming blinded to the text. In trying to move the group 
> forward toward a group concencus, I can only see two ways forward:
> 
> 1) Press ahead with the documents as they are. i think that 
> would likely require mean a process similar to that of a 
> rec-track document (like
> webarch) with issues lists and resolution proposals and negotiations.
> This would likely dominate TAG agendas for a considerable 
> period of time.
> 
> 2) Restructure the document(s) down into bite-sized chunks, 
> each focussed on some particular aspect eg. the use of open 
> content models; version identification; the use of must 
> understand; fallback; and maybe indiviudal strategies aswell 
> indicate when and when not to use a given strategy with 
> exemplars drawn from the use-cases. The revised part 1, 
> focussing on terminology and a model for discussing langauge 
> and language evolution could serve as foundation for the 
> other documents and perhaps be separately published as a WG note.
> 
> Personnally, I think that the the second of these 
> alternatives offers us a more managable way forward. It 
> allows us to publish the things that we can agree on earlier 
> without holding up publication on concensus over the whole 
> document collection at once. It also potentially allows more 
> of use to contribute by moving different pieces along simultaneously.
> 
> I'd be interested in your thoughts on whether this approach 
> might work, or if you have other constructive ideas on how to 
> move this work forward.
> 
> Thank you for all your hard work to date.
> 
> Best regards
> 
> Stuart
> --
> [1] http://www.w3.org/2001/tag/doc/versioning-20070326.html
> [2]
> http://lists.w3.org/Archives/Public/www-archive/2007May/att-00
65/version
> ing-20070326-skw-review.htm
> [3]
> http://lists.w3.org/Archives/Public/www-archive/2007May/att-00
65/version
> ing-20070326-skw-review.doc
> [4] http://lists.w3.org/Archives/Public/www-tag/2007May/0028.html
> [5] http://www.w3.org/2001/tag/doc/versioning-20070518.html
> [6] http://www.w3.org/2001/tag/doc/versioning-strategies-20070518.html
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN
> Registered No: 690597 England
> 
> 
>

Received on Wednesday, 27 June 2007 23:04:32 UTC