Re: SVG examples and test suite

>>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

This means everytime you update RNGs, you run the script.

I read *somewhere* that some tools exist to do so;
therefore, use them and provide them.

http://www.thaiopensource.com/relaxng/trang.html
http://www.thaiopensource.com/relaxng/dtdinst/
http://www.relaxng.org/


"
Jing can validate using the RNG XML syntax
Jing can validate using the RNG compact (formerly "non-XML") syntax

Sun MSV can validate using the RNG XML syntax
Sun MSV can validate using a subset of XML Schema
Sun MSV can validate using a DTD

DTDinst can translate a DTD into RNG XML syntax

Trang can translate the RNG compact syntax into the RNG XML syntax
Trang can translate the RNG XML syntax into a DTD (which may be overbroad)
Trang can translate the RNG compact syntax into a DTD (which may be 
overbroad)

Sun RELAX NG Converter can translate a DTD into RNG XML syntax
	(but does not preserve structure)
Sun RELAX NG Converter can translate a subset of XML Schema into RNG XML 
syntax
	(but does not preserve structure)

Future plans for Trang include generating XML schema syntax and RNG compact
syntax.

There are also tools for dealing with RELAX NG's predecessors: RELAX Core,
RELAX Namespaces, and TREX.
"
>>- 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.

*See above*


>>So, a bunch of examples EXPLICITELY using every possible attributes would 
>>be nice.
>
>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 can understand that it takes time, but it must be done
and it should be done before it is finalized.

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.

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..."

then end up with compatibility issues...
of the before and after the fix was introduced.

>>- To create a 'fake' test suite like SVG 1.1, such that people like 
>>myself,
>>who are more 'visual' than 'textual' can fully understand what is possible 
>>and what is not possible from the current specs !?
>
>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

>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 ?
What are some valid use cases ?
How it should work ?
and exercise it enough such that
you know that it makes any sense at all ?

Just a tought.

Sincerely,
Fred.

Received on Wednesday, 2 February 2005 00:55:41 UTC