- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 24 Mar 2009 16:20:35 +0200
- To: Ian Hickson <ian@hixie.ch>
- Cc: Doug Schepers <schepers@w3.org>, public-html@w3.org, www-svg <www-svg@w3.org>
On Mar 24, 2009, at 06:58, Ian Hickson wrote: > I am arguing that people writing text/html parsers will have an > easier time writing conforming parsers if they can just look at one > document and don't have to look things up in multiple other documents, > with version shears (e.g. implementing one version of HTML which > refers to > one version of SVG while that version has been updated) and other such > problems. The above paragraph seems to contradict the idea that the SVG WG should publish amendments to the list in the future in their own specs but the initial list would be in the HTML5 spec. If a parser implementor is reading the HTML5 spec, how is (s)he to find out that there's an amendment somewhere else? If the implementor is supposed to be able to look at just one document, that document should have the most correct list or a link to the most correct list. Concretely: Should new SVG 1.2 Tiny elements be on the list today (regardless of which WG maintains the list) when browsers differ in their treatment of 1.2 Tiny as part of the platform? Is the issue at hand acknowledging SVG 1.2 Tiny with its normative references to XML 1.1, xml:id, XML Events, Namespaces in XML 1.1 and XSL 1.1 and informative references to WebCGM and XHTML Vocabulary Collection? In practice, except perhaps for textArea, it should be pretty safe to put 1.2 Tiny names on the list even if 1.2 Tiny isn't supported by the SVG implementation of the application that includes the HTML5 parser. For textArea, it should either be safe to add it now or it will never be safe to add it. What's the current guess on 1.2 Tiny camelCase names making it into an SVG 2.0? (What other 1.2 Tiny camelCase names are there in addition to textArea?) > The benefits of putting the list in the same document as that which > defines the vocabulary is purely an editorial and process benefit, it > isn't a benefit to implementors. Benefits to implementors outweigh > benefits to us. I personally would rather not have to maintain this > list > myself, just like I'm sure the SVGWG would rather be in control of > that > part of the HTML parsing rules instead of having to potentially have > cross-working group discussions with each new element; but our own > desires > are the least important concern here, according to our "priority of > constituencies" design principle. If we want the list to be more malleable than the rest of the algorithm definition document, the algorithm spec should have a link to a URI which will dereference to the latest list at any given point in time. A great bonus would be if the document at the URI came with revision history. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 24 March 2009 14:21:23 UTC