Re: please add SVG as option for enforcing DOCTYPE

On Friday, August 4, 2006, 7:39:22 AM, olivier wrote:

oT> Hi Ruud,

oT> [I'm copying my reply to the qa-dev list, and copying Chris for some  
oT> advice. Please keep the list in copy in your replies. Thank you.]

oT> On Aug 1, 2006, at 23:55 , Ruud Steltenpool wrote:
>> cause i often consider remarks about foreign namespace things pollutin
>> my SVG validation results, I built something that:
>> -assumes a document is SVG (which can include Xlink)
>> - turns <foreign:something><svg:sth /></foreign:something> into  
>> <svg:sth />
>> (Is this how an SVG renderer should work?)
>> - throws out attributes in foreign namespace
>> -sends it off to the W3C validator with DOCTYPE enforced.

oT> I see, so it's a way for you to work around validation issues with  
oT> multiple namespaces documents?

No, not a 'work around' at all. What Ruud is doing is implementing a part
of the SVG 1.1 specification, which defines a conforming SVG document
fragment.
http://www.w3.org/TR/SVG11/conform.html#ConformingSVGDocuments

He is constructing one from his document and then using an
appropriate validator for that fragment. This is entirely appropriate
and spec based.

oT>  Do you also have another way of  
oT> checking all the things in these foreign namespaces, or is the main  
oT> goal to make sure that the part in the svg namespace is at least OK?

The better way to do this (and the only way in SVG 1.2 and above, which
has finally abandoned DTDs in favour of RelaxNG) is to use NVDL to
define the dispatching and then separate RelaxNG (or W3C XML Schema)
schemas for the individual fragments. Thus, the sort of transformations
that Ruud is doing to get document fragments are done automatically.
Also, the RNG corresponds more closely to the text of the specification
than a DTD could, so some of the trimming (eg, qualified attributes in foreign
namespaces  on elements in the svg namespace) is no longer required
soince the SVG RNG already takes care of it.

>> Possible improvements:
>> -Know the full internal list of validator.w3.org DOCTYPEs

oT> These are in the CVS repository for the validator, that may be of  
oT> interest to you:
oT> http://dev.w3.org/cvsweb/validator/htdocs/sgml-lib/sgml.soc
oT> http://dev.w3.org/cvsweb/validator/htdocs/sgml-lib/xml.soc
oT> and also at http://dev.w3.org/cvsweb/validator/htdocs/conf/types.cfg


>> -guess the right DOCTYPE based on the document

That might be of some help (eg, for SVG 1.0,  1.1 Full, 1.1 Tiny or 1.1
Basic) where a DOCTYPE

a) exists
b) might not be there in the instance
c) can be reliably inferred from the namespace, version and baseProfile
attributes.

Guessing, though, should not be encouraged and if often wrong. The W3C
validator often guesses and oopten is incorrect. As an example,sending
it a valid SVG 1.2 Tiny document, the validator confidently proclaims
that the XHYML 1.0 Transitional doctype is missing and that the document
is invalid. A true DTD validator should simply say that the document cannot
be validated.

oT> Hmm, That would be fairly easy done by parsing the version attribute  
oT> of the <svg> element, if present.

Version and baseProfile.

oT>  Less so if the document is not SVG,

Right, you would need to check for the SVG namespace as well and then look for
a root svg element in the svg namespace.

All of this is doable, but its all extra work to extend the life of a
DTD validator that started as an HTML validator for SGML and is showing
its age.

A better approach long term would be to use a more modern and standards
based dispatching approach rather than adding ad-hoc extensions.

oT> but your idea is to run this only on SVG documents, right? Note  
oT> however that AFAIK, there is no doctype for the SVG1.2 family.

Correct, and this is by design. DTDs are entirely unsuitable, and we
finally abandonded them for SVG 1.2.

>> -correctly interprete xmlns used on other then the root element

oT> Any idea how you would use that?

Just the regular way that the XML namespaces spec says, I expect. But
perhaps I am missing the context of the question.

>> What's your opinion on this?
>> Useful as long as clear warnings are present?
>> Maybe an idea for THE validator?

oT> I don't consider myself to be enough of an expert to give a very well  
oT> informed, let alone authoritative, opinion :). It seems to me like a  
oT> useful hack, if multi-ns documents are important to you but you still  
oT> want the benefits of validation for the SVG basis.

Right. And as pointed out, the transformation Ruud is doing is justified
and spec compliant.

oT>  I guess that as
oT> long as all the namespaces involved have a clear schema associated  
oT> with them, a solution based on NRL would be less of a hack,

Agreed (its now called NVDL)

oT>  but I'm
oT> still rather puzzled by how this could be done properly since some  
oT> namespaces are associated to various versions of a technology (e.g  
oT> xhtml), hence different schemas. Bear with me, I am still catching up  
oT> with these issues...

oT> Chris, whom I'm copying in this mail, would probably be way more  
oT> knowledgeable about whether your solution is a good idea or not. I'll  
oT> let him chime in if he has anything to add.

I chimed.



-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Friday, 4 August 2006 12:11:01 UTC