Re: Element Whitelisting

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:27 UTC