- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 4 Sep 2009 17:36:09 +0300
- To: Larry Masinter <masinter@adobe.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
On Aug 17, 2009, at 04:51, Larry Masinter wrote: > I wrote: >>> Conformance checks can use a version indicator (doctype for example) >>> to determine which conservative advice should be applied. > > And Henri replied: > >> Having an in-band version indicator for conformance checking makes >> the >> following unwritten assumptions: > > No, it makes none of these assumptions. OK. >> * It's appropriate for a person opting to target an older "version" >> not to see more up-to-date advice. (Surely newer advice should be >> assumed to be better informed and, thus, better advice.) > > No, there is no such assumption. Your complaint seems to make > the odd assumption that "newer advice" is uniform, i.e., that > versions of languages are somehow uniformly and instantaneously > deployed. I'm not assuming that. What I assuming is that if the newer language makes old language features non-conforming, the old language features are bad right away. > If a newer specification is less conservative than an older > one then the "newer advice" is not always "better informed" > if the goal is to target older consumers. Good point. However, if the use case is targeting old consumers, the validation target should be determined by the feature set of old consumers--not by the feature set of an old spec. They don't necessarily match. It's mostly fiction that consumer version x implements language version n entirely and x+1 implements n+1 entirely. > I mentioned "conformance checker", but of course, the utility > of version indicators is also good for editors, More on this below. > translation gateways, How? Why wouldn't translation gateways want to be as versionless as browsers? Also, I'd argue that standalone translation gateways as a product category are being obsoleted by Opera Mini on one hand and full browser engines on mobiles (e.g. Fennec and Mobile Safari) on the other. > compatibility filters, What are compatibility filters? >> * The user of an editor that embeds a conformance checker using >> product-specific in-band syntax (consider the Emacs mode line) to >> communicate the validation target, and the target choice may be more >> granular than W3C spec versions (making the in-band indicator non- >> interoperable). > > Almost anything can be left to be "product-specific", including > elements of the language itself. We're engaged in standards making > to try to come to a common way that multiple, independent > implementations > can use a common standard. > > There are probably 100 different HTML editors in common use, > http://en.wikipedia.org/wiki/List_of_HTML_editors > and yes, of course, each could use a product-specific in-band > syntax like the Emacs code line to communicate the validation > target. Standard syntax works only to the extent the validation targets are standard. If you want to validate to a subset of the official language so that the subset fits your CMS, it doesn't matter much if place where you put the identifier is standard if the identifier is not. (Consider <html version="my-cms-subset-of-html5">.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 4 September 2009 14:36:49 UTC