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

Hello David,

Thanks for taking my comments on board. Apologies that I have not yet
been able to sit down and take a review pass through the new version as
a whole, however I have taken a pass over you responses below.

BR

Stuart
--
> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com] 
> Sent: 27 June 2007 23:53
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org
> Subject: 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.

The sentence that I was commenting on was:

"Two languages may have the exact same strings but different meanings
for them."

What I was asking about was whether the intention was to say that the
two langauges happened to have some particular strings in common or that
ALL the strings of (at least) one language are also strings of the
other. I see that the sentence persists in the new version.  I was
really only asking that you make it clear whether you were talking about
a particular string common to two languages, or two languages where the
strings of one is a subset of the strings of the other.

"A given string may be admissable in two different languages each of
which derives different meaning from the same string."

	or 

"Two languages overlap such that ALL strings of one language are also
strings of the other, however, each language derives different meaning
from the same string."

I think that for the purposes of what you are writing the first of these
is enough.

> >>" 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.

Ok... the context of the text I'm commenting on has one producer and one
consumer. The producer produces and the consumer consumers. The context
of the text does NOt include a round-trip. So... in the context of a
producer that produces and a consumer that consumes I don't how
upgrading a consumer can possible break a producer.

However, once you enlarge the scenario such that producers also consume
(responses) and consumers also produce (responses) then yes I can see
how the revised responses can break the producer.

I hope that at least explains the 'complaint'. 

> >>"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.

Ok... will review.

> >>"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.

I'll take a look.

> 
> >>"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.

Ok... I'll read this whole section again in the new draft.

> >>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.

Ok... will re-review in the new draft. I guess I need to get a senses of
what the qualifiers  'strictly' and 'fully' are intended to convey.

> >>"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.

I believe that we both understand what you are trying to say, but I
still don't think that a strict reading of what you have written says
what you intend.

As I understand it a member of the Accept or Defined set of a language
is a full document subject to the constraints of that language - not
some substring fragment of a document. I may have got that wrong, but
that was my understanding of what those set were at the time of my
review. With that understanding, taken on it's own, a member of the Name
languages' Defined set doesn't serve as a member of the PO language
Defined Set (or Accept Set for that matter). However, a member of the
Name language Accept Set is admissable as a substring within a member of
PO language accept set (subject to the syntactic constraints on where an
name can be inserted).

The Accept set of a language composed from component languages is surely
much more complicated than the simple union of the Accept sets of the
component languages.

> >>"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.

Ok... what I was trying to say was that in the 'normal' case the more
open language is the earlier one and the later version or extension is
more restrictive. The use case that you give is the other way round.

BTW: Looking at the revised text in this area around (*,given,*) and
"given" being said to be Defined and Accept Sets. The text does say more
clearly that the Accept set is defined by (presumably matches on)
(*,given,*). But it still speaks of "given" as being the Defined Text
Set for the Given Name Language. At best it is a production in a grammar
that can test as string for membership of the set - but it is not,
itself, the set.

> >>"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."

Ok... apologies that the tail of the comment was a bit flippant. I see
that text that you've added. If "Least Partial Language" is a useful
concept (and I think I remain to be convinced) then I think it is
deserving of being stated as a definition rather than simply being
normal running text. Ditto for "Full Languages" in the new paras that
follow.

> 
> Cheers,
> Dave

Many thanks,

Stuart
--
> 
> > -----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
> > 
> > 
> > 

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
RG12 1HN
Registered No: 690597 England
>

Received on Monday, 9 July 2007 13:07:11 UTC