W3C home > Mailing lists > Public > www-svg@w3.org > February 2005

Re: SVG examples and test suite

From: Robin Berjon <robin.berjon@expway.fr>
Date: Thu, 03 Feb 2005 14:35:32 +0100
Message-ID: <420228A4.4090205@expway.fr>
To: "Fred P." <fprog26@hotmail.com>
Cc: www-svg@w3.org

Fred P. wrote:
>>> Would it be possible to:
>>> - Generate an XML Schema from the RNG specs
>>
>> That will be done. Being a W3C WG has many advantages, unfortunately 
>> having to support XML Schema is not one of them.
> 
> I think you really did NOT understand...
> 
> I said GENERATE it using some Java program or Perl script,
> NOT writing or maintaining it by hand ! =P

I did understand and yes it will be generated and not hand edited. The 
output will however have to be inspected by human beings because it will 
be normative, and that's going to be unpleasant.

>>> - Generate a DTD from the RNG specs
>>
>>
>> I doubt that. And even if it were possible, DTDs are totally useless 
>> for SVG (or any other XML language apart from the really stupid ones 
>> from '98 that don't have a namespace) so I fail to see what one would 
>> do with a DTD apart from use it to cure advanced severe insomnia.
> 
> Some embedded XML checkers are still DTD only.

That's their limitation, not ours. DTDs are meaningless in a namespace 
world.

> *See above*

DTDs could be automatically generated but they would be entirely 
useless. They would be able to tell you that some documents very 
carefully authored to work around DTD limitations are valid (and even 
then, a fair number of restrictions would not be supported) but a large 
set of valid documents will be flagged as invalid by the DTD. DTDs are 
hopeless, don't use them.

>> Using every single attribute in an example of the spec would be a huge 
>> amount of work. This is best handled by third parties publishing 
>> articles and books.
> 
> I totally disagree. If you can describe in 10+ pages
> what the specs are doing, you are able to draw
> on a whiteboard an example for every details
> and a short sample of how it works
> unless you have no clue what you are talking about.

I have a good clue what I'm talking about and I can tell you that 
creating examples for every single value/option of every single feature 
is a massive undertaking. I'm not saying it's not valuable, but it's 
certainly not something that I see the SVG WG doing. I also really don't 
see why it can't be done outside of the WG.

> I can understand that it takes time, but it must be done
> and it should be done before it is finalized.

I don't see why it must be done.

> We are talking about SVG 1.2 and
> various piece of it for more than 2 years,
> I think it's more than about time that
> we create examples to illustrate it,
> before it gets "finalize",
> so we can unit test every part of it.

Tests are being written, but they are generally technical and do not 
often work as good examples.

> As a comparision, for me it's like someone saying:
> "Ship the product before we test it,
> let the end user test it if it fails will fix it later..."

I think you're using the wrong terminilogy. If you're talking about 
tests then of course there are tests. Those are useful for implementers. 
But if you're talking about examples that people could use to understand 
the spec, those would have to be done differently, and are not on plan.

>> Creating a 'real' test suite is already so much work that it is hard 
>> to find enough people in the WG to do a good one.
> 
> Use the W3C SVG newsgroups,
> and add [TEST] tag in the subject with a PNG attachment. =P

People are more than welcome to submit test cases to the list. That 
would still require work on the WG's part (as they would need to be 
validated) but would be helpful.

>> A 'fake' one would definitely have to be done elsewhere.
> 
> How can you argue on something like <flow*> stuff,
> if you barely have a clue what's going on ?

By simply having a clue about what's going on in the first place?

-- 
Robin Berjon
   Research Scientist
   Expway, http://expway.com/
Received on Thursday, 3 February 2005 14:17:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 23:39:54 UTC