- From: Ruud Steltenpool <svg@steltenpower.com>
- Date: Fri, 4 Aug 2006 15:03:40 +0200 (CEST)
- To: "Chris Lilley" <chris@w3.org>
- Cc: "QA Dev" <public-qa-dev@w3.org>
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 svg.org ? Cheers, Ruud http://svg.startpagina.nl 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. > 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 13:18:34 UTC