- From: Tobias Reif <tobiasreif@pinkjuice.com>
- Date: Thu, 4 Dec 2003 23:44:17 +0100
- To: Jim Ley <jim@jibbering.com>
- Cc: www-svg@w3.org
On Thu 2003-12-04 Jim Ley wrote: > [...] but Squiggle is mostly an example application for the > excellent renderer it's not something to worry about. Correct, I did not worry about SVG being "doomed". > Relevant ways being the problem DTD validity of SVG doesn't solve > those problems, we need to include non SVG elements to make our > content accessible, to assert our copyright claims etc. Sure! As you know I have been doing this since years. > To render custom content - some our of course more relevant to 1.2, > but lots of it we've been doing in 1.0 and before - See Chaals's > original SVG accessibility resource which was one of my first > introductions to the language, despite the importance of validity, > the accessibility is more important. If one adopts the idea of validity for what it tries to achieve, then these concepts won't conflict. I would never say that accessibility is less important than validity, and I would never recommend to compromise accessibility, and I did not. > DTD validity is the problem, not validity. DTD's aren't rich enough > for mixed namespace XML, there are other mechanisms available. I am very aware of the problematic symptoms that come from the fact that DTDs don't know about namespaces, that's why I have been cheering for years at the WG going with WXS and now (luckily) RNG. I'm not sure how you could get the impression that I would generally favour DTDs over namespace-aware schema languages when validating multi-namespace documents. (The posted SVG was SVG-only with two xlink attributes and referenced a DTD so a DTD validator was useful enough to catch some potentially relevant errors.) > Of course, I was just asking for clarification of what exactly you > meant, If you check the original post you will see that all I did was to supply data meant as useful feedback. Text such as 'The "top" identifier is not a valid value for the "text-anchor" property.', "ID lite already defined", and "No declaration for attribute x of element polygon" for example is generally helpful when debugging the stylesheet and the SVG, in order to increase the chances that the SVG will work in more than one or two players that are available to the autor of the SVG. > given that key events are a requirement for a crossword player and > there's no SVG dtd available that contains them, do you expect L to > produce a custom DTD specifically to address the attribute? Don't > you think that's rather a waste of time considering the value it > would give? But it is his choice to make. As I said, you, him, and I are free to choose different strategies for ensuring correctness of SVG content before publishing it. Any strategy, and toolchain, any combination of tools conncepts and technologies that works is good and appropriate. Validity is important: Duplicate IDs for example can break scripting, animation, and styling; and non-existent (I really mean non-existent objects in the SVG namespace, not just things that are excluded from some DTD) attributes or elements won't really achieve anything predictable across viewers. Validators are useful tools for content authors (and authoring tools) for detecting such validity errors. If the SVG contains stuff that's invalid in respect to a vanilla DTD then each developer can choose from various options: * Manually/visually glance over the code and then publish it. This as you know frequently results in published SVGs which don't even satisfy the validity constraints expressed in the XML spec, eg they contain duplicate IDs (as the posted SVG did). * Extend the DTD in the internal subset. This represents the most simple way in many scenarios (long and complex SVG with just a few lines of RDF or other non-SVG code) Typos are caught easily, non-existent elements (eg typos) and attributes as well (element polygon doesn't have any attribute x (but the posted SVG did have it)). Widely available and very mature DTD validators can be used (for many types of SVG content). * If neither of the previous options are feasible or sensible for one or the other reason (eg an aversion against writing internal DTD subsets ;) the developer could use any other automated QA tool or technology such as an RNG validator, a custom XSLT, NRL [1], or a combination of various tools and technologies. I for example use nearly all of the listed strategies, often in combination. Tobi [1] http://www.thaiopensource.com/relaxng/nrl.html -- http://www.pinkjuice.com/
Received on Thursday, 4 December 2003 17:42:58 UTC