W3C home > Mailing lists > Public > public-svg-wg@w3.org > January to March 2010

Re: Element Attribute and Property tables for Integration Specification [ACTION-2707]

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Wed, 06 Jan 2010 14:27:35 +1100
Message-ID: <4B440327.1060800@cisra.canon.com.au>
To: Doug Schepers <schepers@w3.org>
CC: W3C SVG Public Working Group <public-svg-wg@w3.org>
Hi Doug,

Given the issues with farming the table data from the various specifications and 
then putting it together, I've decided to start from scratch and make a script 
that pulls in the data from the "definitions.xml" file of each specification. 
Using that data the script will generate the final table for the integration 
specification.

I will provide a progress update at the next telephone conference (2010-01-07).

Cheers,

Anthony

Doug Schepers wrote:
> Hi, Folks-
> 
> I tried (again) to publish SVG Integration, but after 4 hours or so, the 
> tables once again defeated me.
> 
> Both tables have many broken links, and here are a few of the problems 
> with the attribute/property table:
> 
> * Some attributes are duplicated over different rows... for some 
> attributes, each element has a separate row for SVG 1.1, while these are 
> normally correctly collected together for SVGT1.2 (this leads to 
> duplicate row ids, and thus invalid documents unusable as a spec that is 
> meant to be referenced)
> * SVGT1.2 had the wrong element name and link for <linearGradient> 
> elements (about 20 times)... it linked to the <line> element instead... 
> this may be a problem with the schema
> * there are no properties at all, just attributes
> * lots of problems around the xlink:*/xml:* attributes (damn namespaces!)
> ** all of the xlink:* attributes are missing their text content for the 
> attribute name column (for SVG11) or just have "xlink" (for SVGT12)
> ** xlink:show has weird duplication/aggregation pattern for SVGT12
> 
> I've tried to correct the tables manually, so we can publish it as-is 
> this time, but couldn't get it done in time.  Maybe we can look at the 
> process for how these are generated and fix it for the next attempt. 
> Doing it manually is just silly, but I didn't know the script at all, 
> nor where the data is mined from.  The Perl script had no comments and 
> no readme, so I didn't even try to fix it.
> 
> Since this is not just a one-off (I expect this document to be 
> maintained over time), we need to be much more systematic about this, 
> and to document the process so we any of us could pick it up.
> 
> Here are a few questions that would help me understand the process better:
> * Where is the data coming from?
> ** Was it scraped from the spec, mined from schema or DTD?
> ** Can we format that data better for reuse?
> * How do the scripts work?
> ** What steps are involved?
> ** I take it that there is a script that creates the data for each of 
> SVG11 and SVGT12, then another script that collates them together?
> 
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
Received on Wednesday, 6 January 2010 03:28:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:42 UTC