- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 9 Sep 2009 09:31:16 +0300
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Shelley Powers <shelleyp@burningbird.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-html@w3.org, Lachlan Hunt <lachlan.hunt@lachy.id.au>
On Sep 9, 2009, at 02:21, Maciej Stachowiak wrote: > On Sep 8, 2009, at 3:49 PM, Jonas Sicking wrote: > >> On Tue, Sep 8, 2009 at 3:15 PM, Maciej Stachowiak<mjs@apple.com> >> wrote: >>> >>> >>> I think in an earlier message, Henri outlined the possible options >>> for >>> dealing with this (specifically in the context of <metadata>, but >>> I think it >>> applies to SVG in general).[1] I think his option (3) is probably >>> the most >>> reasonable, all things considered. The DOM Consistency violation >>> is only >>> theoretical, because the content in question is generally not >>> meant to be >>> processed by the client. I think his options (1) or (3) could be >>> implemented >>> by errata to the SVG 1.1 spec to make clear how SVG conformance >>> rules apply >>> in text/html. His option (2) would require changes to the HTML5 >>> parsing >>> algorithm, but it doesn't seem to be anyone's preferred option. >> >> Surely this data is expected to be consumed by *some* client, right? When an HTML author copies and pastes some Inkscape-created or Illustrator-created SVG clip art (e.g. from Wikimedia Commons), I'd expect the HTML author to have no expectations of how either metadata or product-specific state data be processed other than that it doesn't interfere with vector graphic rendering. For this use case, it's entirely unhelpful for a validator to complain either about what was metadata in SVG/XML or about what was product- specific state in SVG/XML when pasted to text/html. In particular, removing this cruft manually in a text editor is too labor-intensive for too little gain. However, it would be fair to emit one warning suggesting the use of a file size optimizer that zaps the cruft without manual labor in a text editor. For this use case, it's also unnecessary to define any non-validator processing that isn't already defined. In the rare case where the HTML author actually tries to express metadata and expects it to be processed as RDF/XML, it would be reasonable to throw errors to signal that what looks like RDF/XML metadata isn't, in fact, RDF/XML when parsed as text/html. Since this case can be expected to be rare compared to the above case and since a validator cannot know which case it is dealing with, on balance, a single warning is probably the most useful compromise even though it's technically wrong not to flag bogus markup as errors. On the other hand, even though RDF/XML is in principle supported in SVG/XML, it's probably equally wasteful to spend time adding RDF/XML metadata to SVG/XML on the Web (in terms of what one can expect about someone processing the metadata as an RDF graph and deriving value from it), so keeping that in perspective, it's not significantly more wasteful to put RDF/XML-looking stuff in text/html. Can anyone show me products that ingest RDF/XML from SVG/XML, build an RDF graph and do something useful (other than merely displaying it) with it? As for the use case of a future version of Inkscape trying to round- trip its state when reading its SVG/XML output that has been pasted into text/html, what Maciej says below applies. >> And we'd need to define parsing rules that that client can use to >> consume the data, no? > > I think in most cases the data is expected to be consumed by the > authoring tool that created the SVG in the first place. They are > storing information that is of interest to further editing of the > given SVG by the original tool, but not to mere display. If such > tools are ever updated to directly save and load SVG-in-text/html, > then indeed they will have a problem. They'll either need to store > their authoring state metadata differently in HTML serialization, or > at least expect that when parsing the HTML serialization, the > metadata is expressed differently. So indeed, these authoring tools > (but not UAs or Web content) would face a DOM Consistency problem. This bothers me, but I don't have a solution that isn't bad in some way. It bothers me less than DOM Consistency problems in the parts of the language that are meant to interoperate between multiple products, though. It would be possible to grandfather a fixed set of Inkscape attribute names into the pre-interned tables of well-known attribute names so that those attributes would get the same magic as xlink:href, but I can see how that could be seen as unfair favoritism towards one product that would bloat everyone else's footprint and it still wouldn't deal with the Inkscape elements. I'd oppose grandfathering Inkscape elements, because they don't fit into a mechanism existing for other reasons. The stuff Illustrator outputs is too varied and crazy to grandfather, in my opinion. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 9 September 2009 06:32:01 UTC