Re: SVG crosswordplayer first release!!

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