Re: SVG and proper XML design

Hi,
>  Why is this a problem?
>  Consider the perspective of the language implementer (i.e. someone
> who write a program to parse and/or modify SVG).
....
>  This means I can no longer use a simple string tokenizer, but
> instead have to write a state-machine style parser. This totally
> violates the purpose of an XML language. XML grammars are not about
> saving space! They sacrifice meaningless savings in space for the
> benefit of ease-of-use and ease-of-implementation.
Space isn't the only reason for some of the SVG language definitions,  
it needs to
be possible (within reason) to parse and render documents quickly  
(remember
modern web engines are measuring page render times in milliseconds)

XML (even with a fast parser) is still slow to parse, especially  
compared to
something as concise as the path definition language defined by SVG, so
it's not efficient from a runtime point of view (more mark up means  
more IO,
more complex parsing) -- although i admit it could be less efficient  
from
the perspective of writing an implementation.

>  So what is my recommendation?
>  Simple: Create an XML grammar definition for paths and other
> arbitrary string formats such as style. It would be much easier to
> parse the language of it the grammar included something like:
>
I think that does look perfectly reasonable, and were it not for my  
the above efficiency reasons
something along those lines would be not necessarily be bad

--Oliver