Pankaj,
When the March 3 spec was first announced to the public, there were a
series of emails submitted to www-svg@w3.org that expressed negative
sentiment about having two different grammars. You can check the email
archives at http://lists.w3.org/Archives/Public/www-svg, and start looking
at the postings on March 6.
The SVG working group is well-aware of this public feedback. We are
well-aware of the extra complexity that is introduced when you offer two
ways of doing the same thing. The reason behind the redundancy is explained
(at least partly) in the specification at:
http://www.w3.org/TR/SVG/intro.html#TwoDTDs. A key bit of wording is the
following, which comes from that section:
"...Because Stylable SVG requires the use of a styling language before
rendering properties can be attached to graphics elements, and because
Stylable SVG allows arbitrary styling languages to be used, Stylable SVG is
not suitable as a self-defined, fully-contained language format for
guaranteed interoperability. With Exchange SVG, all rendering properties
are expressed as XML attributes rather than using the syntax of a
particular styling language...."
The main reason for the redundancy is the following two conflicting and
equally valid needs:
1) In favor of Stylable SVG: Syling with CSS is a very useful addition to
SVG in some cases, such as when SVG fragments are included inside of other
CSS-styled XML (e.g., XHTML)
2) In favor of Exchange SVG: It is a requirement for many applications that
SVG be a usable grammar without requiring a particular styling system such
as CSS
The March 3 spec addresses the two conflicting requirements by introducing
redundancy, thereby providing language features that address both sets of
requirements. But this redundancy comes at a cost in term of added
complexity, which the public feedback has pointed out clearly.
Jon Ferraiolo
SVG Editor
Adobe Systems Incorporated
At 11:12 PM 4/19/00 -0400, Pankaj Kamthan wrote:
>What was the rationale of the SVG WG for having
>two [1] namespaces for SVG?
>
>Thanks.
>
>Pankaj Kamthan
>
>[1] And not one, like, for example, XHTML 1.0.
>