Re: please add SVG as option for enforcing DOCTYPE

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

in the appendix "RelaxNG Schema for SVG Tiny 1.2"

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
the conformance for a Conforming SVG Document Fragment is now expressed
as an NVDL grammar

More details

ISO/IEC 19757-2 

ISO/IEC 19757-4

I also suggest looking at the Relaxed validator (the docbook one,not
the html one)

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

Yes. Nice one.

RS> Cheers,

RS> Ruud

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

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