- From: Philip Taylor <pjt47@cam.ac.uk>
- Date: Sat, 09 May 2009 21:02:48 +0100
- To: Shelley Powers <shelleyp@burningbird.net>, www-archive@w3.org
[Removed from public-html since I don't think I'm saying anything interesting enough to bother everyone with,] Shelley Powers wrote: > I noticed, though, that folks were allowed to mention SVG in relation to > the use cases when it comes to the vector graphics discussion. We're not > been able to say the 'R' word in the discussions related to metadata. > > Come Monday, I may get naughty, litter the 'R' word all about, like > elephant droppings that you ignore at your own peril. It's probably also worth noticing that the problem statements and requirements/priorities in http://wiki.whatwg.org/wiki/New_Vocabularies don't mention SVG at all; only the proposed solutions do. The mailing list discussions mentioned SVG a lot, but the use cases were extracted from the discussions in a way that doesn't completely presuppose the solution, and those use cases were adequate justification for adding SVG to the spec as the best solution for some. The use cases were still written with SVG kept in mind. It provided a way to group similar use cases (so people could suggest use cases which could perhaps be solved using SVG), supporting some coherence in the analysis. It also provided a way to see that certain use cases are sensible to consider (e.g. "I want to put scriptable 2D vector graphics in my page") because some approximate solutions already exist and so it's demonstrably possible, versus use cases that are not worth seriously proposing (e.g. "I want to put photorealistic 3D animations with AI-controlled characters and physics simulation into my page"). But at some point it's necessary to step back from SVG, to allow other solutions to be examined, rather than immediately diving into the details of SVG and potentially missing other ideas. In the current idealised HTML5 process, that stepping-back point is just before you write the problem statements and requirements in the use cases. So problem statements like "I want to use SVG/RDFa in text/html to do X" are likely to get the response "But why do you want to do that?", and you would need to step back and say "I want to do X" (and accept that X might be solved without involving SVG/RDFa at all). So the problem statements should be more like "I want to mix scriptable vector graphics with my HTML content without migrating to XHTML" or "I want to mark up a complex data structure representing various types of product in my online store, so somebody can easily write software to process the data and compare products between other similarly-marked-up stores" (though that doesn't carry much weight if it's purely hypothetical rather than coming from someone who's really trying to do that). Otherwise the discussion is unlikely to be productive. Anyway, I'm sure I'm not saying anything new; I just want to attempt to explain why making the use cases dependent on RDF(a) is probably not going to go down well, but it can still be very relevant in other parts of the process. -- Philip Taylor pjt47@cam.ac.uk
Received on Saturday, 9 May 2009 20:03:24 UTC