[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
[email protected]
