W3C home > Mailing lists > Public > www-svg@w3.org > December 2003

Re: SVG crosswordplayer first release!!

From: Tobias Reif <tobiasreif@pinkjuice.com>
Date: Sat, 6 Dec 2003 20:03:07 +0100
To: Jim Ley <jim@jibbering.com>
Cc: www-svg@w3.org
Message-ID: <20031206190307.GA4372@linux>

On Sat 2003-12-06 Jim Ley wrote:
> "Tobias Reif" <tobiasreif@pinkjuice.com> wrote in message
> news:20031204224417.GA4291@linux...
> > But it is his choice to make. As I said, you, him,
> Now I've never met L, but I do know friends of hers, and I believe
> she's female...

Sorry L :)

> > * 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)
> You're speaking as if creating these internal subsets are easy,

Not correct, I specifically wrote that this is a simple task when
there are "just a few lines of RDF or other non-SVG code". Even then
you're obviously free to *not* write an internal subset (as you make
me keep on repeating). The above was listed as one of various
different possible strategies.

> they're not, they're complicated to author,

Sure they are in many cases, that's why I wrote
"* If neither of the previous options are feasible or sensible [...]"

> they're redundant bytes (they achieve nothing at all for the bytes
> downloaded unless you wish to validate yourself)

Jim, I know what they achieve and what they don't achieve.

They achieve nothing but helping (some people who want it) with QA,
it's up to each developer in each type of scenario to decide if that's
worth it.

> If such DTD authoring was simple,

It is in some cases, and it isn't in others, I wonder how this is not

> I would expect to see such combined SVG+XHTML+etc. being ubiquitous,
> not the excellent dtd authors of the W3 saying they don't think more
> than the SVG+XHTML+MATHML versions being unlikely.

Jim, you will not succeed with turning the words around in my mouth. I
most obviously never said that authoring DTDs such as the one you
mention would be simple.

> I just don't think this is a helpful suggestions,

I never suggested that anyone should author full DTDs combining
several languages just to include them in the internal subset. (I
didn't even suggest to L that she authors an internal subset, see the
original post. Instead I merely implicitly suggested to fix a CSS
error, and XML errors such as duplicate IDs.)

I clearly implied that each of the listed strategies is useful only in
certain scenarios (that's why I listed more than one possible

I wrote "Any strategy, and toolchain, any combination of tools
conncepts and technologies that works is good and appropriate." So if
you choose a strategy that works for you in your scenario which
doesn't involve authoring internal DTD subsets then be happy and let
others decide for themselves.

I never suggested to author internal subsets in all scenarios. A DTD
validator generates some useful error messages even if there is
no internal subset, so providing the error messages didn't suggest
anything but to act on them in any way the author of the SVG thinks
is best.

> showing how Schema validation could be done on SVG would be much
> more useful,

Just do it then. This would be "much more useful" than labeling the
contributions of others as useless, thanks.

I have been posting related stuff since a while
In this post for example
I list a command line showing how to validate an SVG against an RNG

Also see

> as at least that would be meaningful in the future, DTD validation
> won't be.

In certain types of scenarios it will continue to be useful, but
you're very free to completely abandon and ignore the DTD schema
language. Even then you'll still have to respect that others choose
different strategies (and even dare to talk about them).

As you keep on trying hard to misunderstand me and also keep arguing
against things I've never said this discussion turns into an
unconstructive experience which is not worth continuing.


Received on Saturday, 6 December 2003 14:01:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:59 UTC