http://www.w3.org/2002/09/wbs/40318/issues-4-84-objection-poll/ wouldn't let me enter the following response as objections to http://lists.w3.org/Archives/Public/public-html/2010Jan/0015.html so per Mike Smith's advice, I'm posting my objections to www-archive and will reference them from the poll.
- - I strongly object to adopting this Change Proposal. I object to rationale point #1 being considered valid rationale. The rationale point claims to make history and use clearer, but the proposal does neither. The proposal introduces new permitted syntax. New syntax doesn't clarify history. Having more syntax doesn't make use clearer. Having less syntax makes use clearer. I object to rationale point #2 being considered valid rationale. The proposal introduces new syntax while the rationale point talks about conformance of previously conforming stuff. Thus, the rationale point isn't relevant to what the proposal actually proposes. I object to rationale point #3 being considered valid rationale. Even if the feature were in scope, it alone isn't a sufficient reason to have the feature. The email cited by the change proposal argues that "controlled environments" are in scope because Members who are more concerned about "controlled environments" than about the public Web fund the W3C. Who funds the W3C may be relevant to who has a say in the chartering process, but once chartered, who funds the W3C should have no bearing on what's in scope for a given WG. The group is chartered to produce "A language evolved from HTML4 for describing the semantics of documents and applications on the World Wide Web." and the World Wide Web isn't a 'controlled environment' in any useful sense. In particular, no one has "operational control" over it in the sense described in the referenced email. I object to rationale point #4 being considered valid rationale. The rationale point cites the intent to support "polyglot" documents as a rationale. However, as far as the doctype goes, polyglot documents have already been enabled and there's no need to introduce more permitted doctypes. (See also http://lists.w3.org/Archives/Public/www-tag/2010Feb/0144.html ) I object to rationale point #5 being considered valid rationale. The distinction between what's meaningful and what's syntactic sugar in XML has been correctly modeled in the SAX API: Anything that's not exposed via the ContentHandler interface is not meaningful. The doctype is not exposed via the ContentHandler interface. If there were a good reason to have versioning information (I think there isn't), the information should use syntax that is exposed via SAX ContentHandler when processed as XML. Furthermore, I object for reasons stated in http://hsivonen.iki.fi/doctype/#xml as if they were fully restated herein. I object to rationale point #6 being considered valid rationale. If this proposal doesn't have any engineering effects, the proposal is pointless. If the proposal is pointless, it should be rejected. On the other hand, if the proposal does lead to engineering effects, it should be rejected for the reasons stated by David Baron. I object to rationale point #7 being considered valid rationale for introducing more syntax. Rationale point #7 makes a statement of appropriateness about an editorial phrasing. Regardless of the appropriateness of the editorial phrasing, this is not a valid reason for introducing any syntax. I object to rationale point #8 being considered valid rationale. If there is "version of the specification" syntax available there's a risk of it being used as a "version of implementation" switch when a vendor wants to masquerade a "version of implementation" switch as non-proprietary. Thus, *any* versioning syntax carries the risk of being used as a "version of implementation" switch. Note that Microsoft implied they would have used version information as an implementation switch: http://lists.w3.org/Archives/Public/public-html/2007Apr/0305.html I object to rationale point #9 being considered valid rationale. If you don't want software to modify its behavior in response to syntax, don't have that syntax. Having a syntax that's not supposed to have any effect is like setting up an attractive nuisance by creating a false affordance. I object to rationale point #10 being considered valid rationale. The proposal offer no data about what characteristics are needed for "compatibility with existing deployed XML editing workflows". I object to rationale point #11 being considered valid rationale. The possibility of future changes is no reason to introduce versioning now. If there's a need for explicit versioning later, versioning can be introduced when it's needed. There's no need to take action now. (Though I doubt the need ever arises.) I object to introducing versioning in anticipation of a future need due to the bad investment characteristics of such a change (detailed by Adam Barth in http://lists.w3.org/Archives/Public/public-html/2010Jan/0295.html ) Furthermore, the rationale point makes the sweeping claim "In the history of computer languages, there are no languages that have not evolved, been extended, or otherwise 'versioned' as long as the language has been in use. This applies to network protocols, character encoding standards, programming languages, and certainly to every known technology found on the web. There are no known cases where a language hasn't gone through some at least minor incompatible change." Even if this claim were true, no evidence or reasoning derived from the claim is provided to support the conclusion that version identifiers are necessary. C, C++ or Java source files don't declare what version of C, C++ or Java they are written in. UTF-8 works without declaring which version of Unicode is being used. I object to rationale point #12 being considered valid rationale. We shouldn't complicate the language in memory of SGML anymore. I object to the impact section, because I think it doesn't accurately describe the probable impact. Specifically, it omits the impact described above in the objection against rationale point #8. I object to the first paragraph under "9.1.1 The DOCTYPE", because is calls the doctype an "element" and talks about "when HTML was defined as an application of SGML" without mentioning that HTML wasn't implemented as an application of SGML and that HTML violated the requirements SGML itself placed on applications of SGML. I object to the proposed replacement text that vaguely describes existing behavior, because the specification should focus on being precisely prescriptive. I object to introducing new syntax that the proposal itself recommends against using. If it's bad stuff to the point of recommending against, there's no point in introducing it. I object to permitting varying "PublicIdentifiers" or "SystemIdentifiers", because these could be used as vehicles of proprietary behavioral switches in the clothing of standardized features, and propriatery behavioral switches can become enablers of vendor lock-in due to increasing the cost of competitive implementations by letting Web content depend of product-specific behaviors. Again, see http://lists.w3.org/Archives/Public/public-html/2007Apr/0305.html for substantiation why this is a real concern and not a theoretical one. Also note that the quirks mode switch that exists now was created as a system that gave after-the-fact meaning to existing syntax surface, so to prevent such after-the-fact giving of meaning, the syntax surface must not be put there in the first place. While not having versioning syntax can't prevent the introduction of proprietary switches (such as X-UA-Compatible), it is fair to assume that we get fewer such switches when the switches can't masquerade as standard features. I object to the claim "however, this proposal is compatible with most widely deployed XML software", because it isn't backed up by any evidence. Note that the author of the proposal didn't post a reply to http://lists.w3.org/Archives/Public/public-html/2010Mar/0216.html Finally, I object to making any of the proposed changes, because we shouldn't make changes based on unsatisfactory rationale (see my objections to each rationale point above). -- Henri Sivonen [email protected] http://hsivonen.iki.fi/
