- From: ashok malhotra <ashok.malhotra@oracle.com>
- Date: Mon, 14 Apr 2008 10:13:32 -0700
- To: Marc de Graauw <marc@marcdegraauw.com>
- CC: noah_mendelsohn@us.ibm.com, orchard@pacificspirit.com, www-tag@w3.org
It was, indeed, the inclusion of Programming Languages in the scope that worried me. Ashok Marc de Graauw wrote: > Noah, > > I think you're right that the problem area is wider than markup languages, but I > agree with Ashok that all artificial languages is too wide a scope. I've > commented that programming languages don't fit in well with the Finding: source > code usually doesn't have a version identifier, 'ignore unknown' is most often > not a desideratum in source code (see my Python 3 example in [1]) , etc. > > I think the difference is more or less between languages which contain data > (including text) and languages which contain instructions. Admittedly this is a > vague criterion, since there are abundant examples of languages which cross this > line, but still, it seems the general direction to take. > > But it's certainly true that the Finding does (mostly) apply to non-markup > data-oriented languages. > > Regards, > > Marc > > [1] http://lists.w3.org/Archives/Public/www-tag/2008Apr/0082.html > > | Ashok Malhotra writes: > | > | > Thus, the heart of the finding is section 5. So, I feel we > | should fix > | > the earlier parts and state clearly our focus on markup > | languages and > | > their problems. > | > | Well, this seems to be an area where some of us have differing > | inclinations, and I'm afraid Dave will feel pulled in different > | directions. Dave's original work several years ago focussed > | mainly on XML > | in particular. Some of us felt that it was important to set out the > | general principles in terms that are more general than markup > | languages > | specifically. Forwards and backwards compatibility, and how > | one models > | the interpretation of new language features by older > | processors, seems to > | be a foundation that one needs independent of whether the new > | features are > | realized as markup or in other forms. Also, in practice, > | markup-based > | languages have lots of content that's not explicitly marked > | up, such as > | the contents of XML attributes and text elements. The rules for > | "versioning" these sublangages tend to be very similar to the > | versioning > | of documents in non-markup languages. Thus, discussing only the > | evolution of the markup itself really doesn't address the problem in > | general, even for languages that are markup-based. Finally, I > | think the > | finding needs to reflect the intentions of the TAG as a > | whole, and at this > | point it's the more general analysis that the TAG has spent > | most time on. > | I suspect Dave would have been happy enough if we had done a more > | markup-specific finding, but I think we will do a better > | service to the > | community if we can set out some of the more fundamental issues in > | versioning. > | > | Noah > | > | -------------------------------------- > | Noah Mendelsohn > | IBM Corporation > | One Rogers Street > | Cambridge, MA 02142 > | 1-617-693-4036 > | -------------------------------------- > | > | > | > | > | > | > | > | > | ashok malhotra <ashok.malhotra@oracle.com> > | Sent by: www-tag-request@w3.org > | 04/13/2008 03:54 PM > | Please respond to ashok.malhotra > | > | To: orchard@pacificspirit.com > | cc: www-tag@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM) > | Subject: Re: Updated Versioning Strategies document > | > | > | > | Dave: > | My action was to review only sections 2 and 4 but I ended up > | reading the > | entire document in fair detail. > | > | My initial reaction was surprise at the scope of the document. You > | address versioning of all (artificial) languages. With such a broad > | scope it's difficult to make sharp recommendations. Thus, the > | first part > | of the finding reads like a tutorial on versioning. But then I got to > | section 5, which is focused on markup languages and their > | problems i.e. > | using existing software (browsers) with new versions of the > | language and > | the document got much more focused and useful. > | > | Thus, the heart of the finding is section 5. So, I feel we should fix > | the earlier parts and state clearly our focus on markup languages and > | their problems. > | > | Specific Editorial Comments > | > | Abstract: > | > | "Separate documents contain the terminology definitions and > | XML language > | specific discussion". Please add pointers. > | > | 1. Introduction > | > | 1. The language should be extensible i.e. . (few words here) > | > | 2. " . text of a language ." I don't like this. Seems to talk > | about the > | documentation. Perhaps you mean "statements of a language" or > | "sentences > | in the language" > | > | 3. " .. a given language version should define a set of compatible > | future version identifiers." Hard to do since I don't know > | what future > | versions of the language will contain. > | > | 1.2 Kinds of Languages > | > | Bug in reference under bullet 3. > | > | 2.1 Why Have a Strategy? > | > | " . there are many messages that don't use any features of the new > | version or perhaps it is appropriate to simply ignore components that > | are not recognized." > | > | You have discussed only language text so far. Where do messages and > | components come in? > | > | "Often, what is needed is some sort of middle ground solution." What > | might such a solution look like? > | > | Remainder of 2 and 4. You give examples of RSS and HTML but other > | examples of use/misuse of version numbers and other strategy would be > | really great! I realize this requires a great deal of work. > | > | 5. Java did remove features by marking them as > | 'deprecated'and providing > | compiler warnings and then removing them in later versions. > | > | At the end of the section you say "select one of the following 3 > | alternatives" but there are only 2 alternatives. I prefer the second. > | > | 5.1 The SOAP MustUnderstand is not a language feature. It's a > | directive > | to the processor. > | > | "Choosing to ignore the container node only helped HTML considerably, > | but there are some elements who's children also should be ignored for > | rendering, particularly the /Script/ element." I'm not sure what you > | meant to say. Is this sentence missing a "not". > | > | 7. I would remove the last sentence. It seems to have a typo as well. > | > | All the best, Ashok > | > | > | > | Dave Orchard wrote: > | > Based upon feedback from Noah, the TAG's Feb f2f, and phone > | > discussions with Noah. > | > http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies > | > > | http://www.w3.org/2001/tag/doc/versioning-compatibility-strate > | gies-20080328.html > | > | > These are now ready for review by Ashok, Dan, Noah, Norm, and Raman > | > per our agreements at the Vancouver F2F in > | > http://www.w3.org/2008/02/26-tagmem-minutes#ActionSummary > | > Cheers, > | > Dave > | > | > | -- > | All the best, Ashok > | > | > | > | > | > > -- All the best, Ashok
Received on Monday, 14 April 2008 17:28:27 UTC