- From: François Yergeau <francois@yergeau.com>
- Date: Mon, 10 Apr 2006 17:41:06 -0700
- To: public-i18n-core@w3.org
-------- Message original -------- Sujet: [Bug 3075] XML 1.0 or 1.1 user override Date: Tue, 11 Apr 2006 00:33:20 +0000 De: bugzilla@wiggum.w3.org Pour: francois@yergeau.com http://www.w3.org/Bugs/Public/show_bug.cgi?id=3075 ------- Comment #3 from noah_mendelsohn@us.ibm.com 2006-04-11 00:33 ------- francois@yergeau.com writes: > I'm afraid the comment was misunderstood. > The Note in the spec says that implementations > MAY provide the heuristic to choose 1.0 or 1.1 > based on the input, but then SHOULD provide an > override of that heuristic. If an application > is hard-wired for 1.0, then it will not have the > heuristic at all, the SHOULD -- which we argue > should be a MUST -- becomes non sequitur and will > not cause the requirement of any never-executed code. Oops. I should have checked more carefully. Still, in spite of that misunderstanding, I think the spirit of my original comment applies. If the invoking application is known always to want the heuristic applied, then what business of ours is it to insist on an API that will never be used? I do agree that in practice, the amount of code involved in adding such an unused API switch will be lower than adding a whole new type system, but it's still a complexity about which I think the schema spec should say little if anything. I have always believed that our main purpose in Parts 1 and 2 should be to define the language and its interpretation, and not the packaging of or interface to processors. I do think it makes sense in principle to >separately< document processor APIs and packagings that are likely to be of common use. Still, I generally expect to see programming languages documented separately from the APIs, command line switches, or debug options of their compilers. I think similar considerations apply here. Noah
Received on Tuesday, 11 April 2006 00:41:08 UTC