- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 9 Sep 2008 22:36:21 +1000
- To: public-svg-wg@w3.org
Chris Lilley: > ACTION-2099 > Review the corrections to the mistakes in the attribute index and > report back > > I reviewed the appendix - particularly wrt the schema - and did not > see any issues that needed correcting for publication. > > It would be *nice* but not required, to change the values on > properties so that 'inherit' came in a consistent position in the list > (eg, last) but that is an editorial matter. Done. > It would be good for the attribute names in the table to be linked > to the corresponding section of the document, like properties are. I > understand the attribute appendix is auto generated; where is the raw > data stored? i wouldn't mind updating it so the attribute appendix has > links to the definitions. Again, this is an editorial nicety and is > not required for publication. There isn’t a file mapping attribute names to spec location. There’s master/elements.txt and master/properties.txt for element and property definition links. Someone could make one for the attributes, but this’d need to map (element, attribute) pairs to spec location (possibly with a wildcard for the element, to handle common attributes). Chris Lilley: > Of course, as soon as I sent that, i saw that id is listed twice, as > ID and as NCName. The two entries should be combined. It should say, > for the type > > <ID> | <NCName> > > and the attribute name should link to the definition, at > struct.html#idAttrs I wonder if the way id/xml:id is defined in the schema is related to ISSUE-2009? Anyway, I’ve special cased id in the table generation script so it comes out as one line. -- Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 9 September 2008 12:37:05 UTC