W3C home > Mailing lists > Public > public-qa-dev@w3.org > August 2006

Re: please add SVG as option for enforcing DOCTYPE

From: Chris Lilley <chris@w3.org>
Date: Fri, 4 Aug 2006 16:04:37 +0200
Message-ID: <17910716819.20060804160437@w3.org>
To: "Ruud Steltenpool" <svg@steltenpower.com>
Cc: "QA Dev" <public-qa-dev@w3.org>

On Friday, August 4, 2006, 3:03:40 PM, Ruud wrote:

RS> Chris, qa-dev.

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

Those allooklike very usefulthings for content authors.

Please add "you don't have a viewBox, but you specify a fixed width and
height; your graphic will be more scalable by setting width and height to
100% and the viewBox to 0,0,width,height"

RS> I was fully aware there's non-DTD validating and i'm looking forward to
RS> it. How much however is there NOW, or rather soon, to help me with my
RS> multi-namespace (incl.SVG) debugging?

I'm pressed for time tight now (important meeting in a few hours) but
here are some quick pointers:

oXygen and Exchanger XMLProfessional both have RNG and NRL (precursor to
NVDL) support.  Hopefully Trang is being updated to NVDL soon. XMLLint
(and libxml2 in general) has RNG support.

RS> I thought the situation is: there are free tools around (installable,
RS> don't know about a service) that validate against RNG, but there's only a
RS> non-official 'svg.rng' somewhere. Correct?

No. I don't know where that rng comes from or indeed which one you refer
to; and the official one is not called svg.rng

RS>  Any guesstimates on when the
RS> official svg.rng is out, or how useful a current is?

The official RNG is linked from the specification
http://www.w3.org/TR/SVGMobile12/

in the appendix "RelaxNG Schema for SVG Tiny 1.2"
http://www.w3.org/TR/SVGMobile12/schema.html

You can get 'dated' or 'latest' versions and you can also download a zip
of the whole thing (again, dated or latest).

For how to use SVG and NVDL, see
http://www.w3.org/TR/SVGMobile12/conform.html#ConformingSVGDocuments
the conformance for a Conforming SVG Document Fragment is now expressed
as an NVDL grammar

More details

RELAX-NG
http://www.jtc1sc34.org/repository/0362.htm 
ISO/IEC 19757-2 

NVDL
http://www.jtc1sc34.org/repository/0694c.htm
ISO/IEC 19757-4 

http://relax-ng.org/
http://nvdl.org/

http://www.thaiopensource.com/relaxng/trang.html

I also suggest looking at the Relaxed validator (the docbook one,not
the html one)
http://relaxed.vse.cz/docbookvalidator/

which uses rng with embedded schematron, and validates,for example,a
mixed namespace docbook+svg+mathmldocument.

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

RS> Chris, seen my bookmarklets (maybe Firefox extension later) thing on
RS> svg.org ?

Yes. Nice one.

RS> Cheers,

RS> Ruud
RS> http://svg.startpagina.nl




RS> 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
>>





-- 
 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 14:05:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:46 GMT