Re: [Fwd: [Moderator Action] Adding private elements and attributes to the DTD]

Robert Diblasi wrote:
> 
> Tobias, Adobe....oh why not ...everybody who cares to read this note :-)
> 
> <tobi_wrote>
> "the adobe-viewer just ignores all elements that are
> not SVG-elements, and all their contents."
> </tobi_wrote>
> 
> I have noticed this too.
> <rant>I find it kind of disturbing! Maybe I am missing something and please forgive me if I am.
> 
> -Does  Adobe SVG viewer use a conforming XML parser that validates aginst the SVG DTD(scheme)?

XML parsing requires well-formedness. It does not require
DTD-validation. All SVG implementations that I am aware of corectly
enforce well-formedness. A couple of them also enforce DTD validation
(IBM and CSIRO spring to mid) which means that they fail, for example,
the metadata tests in the test suite.

> If it does not ....I would like to request it does.........thank you

Be careful what you wish for.

> -Does the SVG specification address this XML 1.0 conformance issue. ( I not talking about conformance to the SVG spec, I'm  talking about XML 1.0 validation issues.)

Then you should carefully check the XML 1.0 spec

> I find it quite disturbing when I write code that does not conform to  SVG DTD  and it still
> runs in Adobe SVG viewer....Does SVG spec specify that a viewer must use a validating parser?

No. How would you place content in the foreign object or metadata
elements? I mean, it can be done while keeping DTD valid by using the
internal subset, if you particularly want.

> .....validation against SVG DTD (scheme) is the only way that XML provides to keep SVG ...."SVG" and not some other application of XML.

You mention one other way parenthetically (schemas) and also there is
the namespace mechanism.


> I just want to know if conformance to SVG DTD(scheme)  is of importance 
> to the SVG spec 1.0 when it comes to parseing a XML document.

Validity constraints, no. A DTD can still be used to provide useful
information, such as which attributes are ID, any defaulted attribute
values, etc without enforcing validity constraints. Also, a thorogh
checker would also enforce things that cannot be checked by DTD validity
- such as all that BNF that is in the spec.

> This all revolves around the namespace issue.
> I can see problems with namespace......but to tell you the truth...I kind of like namespace     prefix:namespace=""

So what you are saying is, putting non-SVG stuff in there is okay as
long as it is in a different namespace and not added to the SVG
namespace? I agree.

> ">In short: you tapped into a general problem of XML:
>   >what are applications expected to do with all those
>   >namespaces?"
> 
> This is not a general problem of XML

Yes it is (smile)

> ......It is how to present different applications of XML in a XML document.

Presentation is one aspect of the general problem of how to handle
multi-namespace documents.


> I hope that this sparks debate about SVG and  XML namespace in 
> the SVG community.

Hope so too.

> I am not going after any of the Writers of the SVG spec.....
> I am going after the spec itself....

Uh-huh...

> and the  potential problems of individuals trying to extend 
> SVG instead of creating a new DTD that handles their specific problem.

So if I extend SVG using the internal DTD subset, where would that put
me?

-- 
Chris

Received on Friday, 13 April 2001 14:07:17 UTC