Re: please add SVG as option for enforcing DOCTYPE

Chris, qa-dev.

I started this hacking with the idea for a validator that did more than
just getting MORE strict errors out, but also the option for some advice,
authoring guidelines applied. Just some possible examples:
- "viewbox" illegal here, "viewBox" legal though.
- replacing "123" with "123px" avoids a problem with some viewers, we keep
statistics (not one bit of your code though) for these viewers to help in
deciding what to fix first.
- shortening the style attribute to ... and adding the following
attributes ... is advised for it to make it work in more viewers

I was fully aware there's non-DTD validating and i'm looking forward to
it. How much however is there NOW, or rather soon, to help me with my
multi-namespace (incl.SVG) debugging?
I thought the situation is: there are free tools around (installable,
don't know about a service) that validate against RNG, but there's only a
non-official 'svg.rng' somewhere. Correct? Any guesstimates on when the
official svg.rng is out, or how useful a current is?

Thanks for explaining further (Good to see not everything i thought/hacked
was a total hack and some principals come back in the next generation of
validators :-) )

Chris, seen my bookmarklets (maybe Firefox extension later) thing on ?



On Fri, August 4, 2006 14:10, Chris Lilley wrote:
> 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.
> 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 DOCTYPEs
> oT> These are in the CVS repository for the validator, that may be of
> oT> interest to you:
> oT>
> oT>
> oT> and also at
>>> -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          
>  Interaction Domain Leader
>  Co-Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
>  Co-Chair, W3C Hypertext CG

Received on Friday, 4 August 2006 13:18:34 UTC