Re: SVG RNGs

Hi Chris,

thank you very much for your reply.
(more below)

On Sun 2003-12-07 Chris Lilley wrote:
> TR> [...]
> TR> http://www.w3.org/Graphics/SVG/1.1/rng/
> TR> [...]
> 
> Correct. If you want to write a multi-namespace document then the
> RNG for SVG only helps with the SVG namespace (and the xml namespace
> and the XLink namespace as used in SVG)

Yes, sure.

In the step where I wanted to validate the SVG (of the type
illustrated with the example 21.3) it's OK if the non-SVG content is
not being validated (otherwise I'd use a custom schema or try NRL).
But since the SVG spec allows "elements from other XML namespaces"
inside metadata the RNG should reflect this, so that my validator will
not flag the RDF as error.

> Luckily in RNG, unlike DTDs, 'any' realy does mean 'any'. So the RNG
> for SVG shouldprobably declare the content model of the metadata
> element as any, ie any old well formed xml is fine here.

I don't yet have a lot of experience with writing RNGs, so
unfortunately I didn't yet succeed with fixing that part of the
current RNG.

This might be a start:

  <define name="SVG.metadata.content">
    <element>
      <anyName>
        <except>
          <nsName ns="http://www.w3.org/2000/svg"/>
        </except>
      </anyName>
    </element>
<! ... but what to write here?... -->

> TR> Is the 1.1 RNG currently being actively developed?
> 
> Not recently, but it should be.

Yes, that would be great, as namespace-aware validation of SVG is not
yet feasible enough. And there's an increasing number of editors which
support context-aware entry help driven by RNGs (for those who want or
need entry help).

> TR> I didn't yet get any replies to
> TR> http://lists.w3.org/Archives/Public/www-svg/2003Sep/thread.html#21
> TR> http://lists.w3.org/Archives/Public/www-svg/2003Sep/0021.html
> 
> Hmm, your svg seems to be correct and the relevant bit of the rng
> seems correct also
> 
>  <define name="SVG.font.content">
>     <zeroOrMore>
>       <ref name="SVG.Description.class"/>
>     </zeroOrMore>
>     <ref name="font-face"/>
>     <ref name="missing-glyph"/>
>     <zeroOrMore>
>       <choice>
>         <ref name="glyph"/>
>         <ref name="hkern"/>
>         <ref name="vkern"/>
>       </choice>
>     </zeroOrMore>
>   </define>
> 
> Which says that font-face, missing-glyph are required element
> children and you have both of those. So I don't see why you get the
> error message you do. Is it just Jing that givs you the error, or
> other RNG processors too?

I don't know how mature the present RNG support is in xmllint and the
error messages are confusing to me sometimes. But since it's much
faster than Jing (no JVM start) it'll probably be the one I'll mainly
use. Anyways, here's what I get:

tobi ~/del $ xmllint --noout --relaxng ~/bulk/xml/schemas/svg/1_1/rng/svg11.rng vimxml.svg
file:///home/tobi/bulk/xml/schemas/svg/1_1/dtd/svg11-flat.dtd:2278: validity warning : Attribute space of element style: already defined
    type %ContentType.datatype; #REQUIRED
    ^
vimxml.svg:32: element font-face: Relax-NG validity error : Expecting an element desc, got nothing
vimxml.svg:32: element font-face: Relax-NG validity error : Element font-face failed to validate content
vimxml.svg:25: element font: Relax-NG validity error : Expecting element font-face, got font
vimxml.svg:25: element font: Relax-NG validity error : Element defs has extra content: font
vimxml.svg:24: element defs: Relax-NG validity error : Expecting element use, got defs
vimxml.svg fails to validate
tobi ~/del $

It seems that there is some problem with the RNG, but I'm not yet
sure.

Can you recommend any RNG validators other than Jing and xmllint?

> TR> [...]
> 
> I was fiddling around with the RNGs on Friday, trying to see how to
> add new modules for SVG 1.2. I was in fact reading your old mails on
> the subject, and made a zip while I was about it. The cvs commit
> comment says 'make Tobi happy' ;-)

Thanks again :)

In the meantime I got the files via

wget -q -nd -A rng -l 1 -r http://www.w3.org/Graphics/SVG/1.1/rng/

> [...]
> TR> but if you must include a doctype decl
> TR> then a real system identifier (plus optional FPI) would be more useful
> TR> for OASIS XML Catalog tools than a relative local path)
> 
> True, although there is a dtd there too now.

The DTD would not have to be downloaded if there was a real system
identifier since it could be used by catalog tools.

You could omit the DTD doctype declaration, and if you had it in there
for validation you could use RNG instead (I use
tobi ~/bulk/xml/schemas/svg/1_1/rng $ xval svg11.rng
svg11.rng validates
xval: schema was /home/tobi/bulk/xml/schemas/rng/1_0/rng/rng_1_0.rng
)
and if you had it in there to drive an editor you could use one which
suports RNG.

> TR> http://www.w3.org/TR/SVG12/#rng-schema
> TR> says
> TR> "This schema should not be considered to be complete or without error.
> TR> Even though it is a schema for SVG 1.1, it is still in development and
> TR> has not been thoroughly tested."
> TR> Perhaps you could publish the latest versions periodically and
> TR> announce them here?
> 
> Sure.

Sounds great!

> Equally, if you find more bugs, please report them

OK :)

> (or indeed, correct the RNGs and mail them in, if you get a burst of
> enthusiasm).

I'll keep on trying while I'm learning more about RNG ...

> TR> 2. Versions, Profiles
> 
> TR> It would be very useful to have a complete and correct RNG for each
> TR> version and profile (not just the planned (normative?) ones for 1.2+):
> TR> 1.1, 1.1 Basic, and 1.1 Tiny (all three would probably simply be short
> TR> drivers referencing a different set of modules).
> 
> Yes it would. Wait,
> 
>  svg11-basic.rng         15-Jul-2003 07:11     5k
>  svg11-tiny.rng          15-Jul-2003 07:11     4k  
>  svg11.rng               15-Jul-2003 07:11     6k
> 
> They are already there?

Awesome!

> TR> [...]
> 
> Ok, you are asking that they be normative, not that they be created.

Having schemas that are as complete and as correct as possible would
help already, and it would be even better if they were normative.

> TR> 4. Instances which don't reference a schema
> 
> TR> If a document doesn't reference a schema (eg a DTD) the path to a
> TR> schema (eg an RNG) must be provided when validating, which is tedious
> TR> to do by hand.
> 
> True, but that is the design in both RNG and XSD and is intentional.

Hard-wiring (eg via a doctype declaration) an instance to something
which can modify the infoset (eg a DTD) and making the process of
reading this resource optional lead to problematic issues: instances
contain different information when read by different kinds of
conforming parsers. But documents which don't reference a DTD could
suggest (not hard-wiring or requiring) one schema (eg an RNG); this
could be done in a way which does not play any role in parsing, so
there should be no issues, it would merely be a suggestion targeted at
humans and validators, not at parsers.

But since this is unlikey to happen in a broad and standard way I'll
continue to enjoy the technical challenge of working around this
problem :)

> Apparently people validate to different schemas at different times.

Yes we do :)
With the above suggestion we still could do so.

> TR>  I've been pondering this issue for the last months, and
> TR> over the last weeks (on and off) I threw together a tiny prototype
> TR> which works well so far (parts of the issue remain though, and can't
> TR> be fixed locally). If someone's interested in the tool drop me a line
> TR> offlist.
> 
> Can I say I am interested onlist, since I am answering this anyway?

Yes :) Sorry for complicating the procedure, but the tool is not yet
ready to be put online, so I'll send it to you offlist.

> TR>  Here's what the catalog looks like:
> TR>  [...]
> 
> Ok so its an automated conditional catalog using Xpath. Neat. Which
> bits can't you fix locally?

Not all schemas require instances to specify their language in a
sufficiently specific way. The SVG WG did a great job, a human or a
software tool can always know which language an SVG document or
fragment is written in: there's the namespace URI, the version
attribute, and the baseProfile attribute (and defaults when some are
absent). With other languages things are less specific: an XHTML
document with no doctype declaration or an XHTML fragment (both in the
XHTML 1 namespace) doesn't specify if it's written in XHTML 1.0
Strict, Transitional, or in XHTML 1.1. A DocBook 4- document is even
more problematic (but 5+ might bring improvements): It's not in a
namespace, and there is no information about the version being used
(it might be specified in a doctype decl which is not available to
tools such as XSLT).

And then there is the issue of fully independent and automatic
validation: If I'm an unsupervised (eg online) validator and my
catalog or language list doesn't know about the language a document is
written in then I have no way of knowing which schema I should or
could use; it would be helpful if instances would at least suggest one
possible schema URL as fallback (since RNG can't modify the infoset of
instances this would not be an issue AFAICS) which I could fetch.

But since this is unlikely to happen, I hope that language designers
understand (as the SVG WG did) that there are benefits for developers
and tools when instances are required to specify their language, RNG
documents for example do this with just one data point:

  namespace-uri(/*)='http://relaxng.org/ns/structure/1.0'

This is fully sufficient for identifying the language (doesn't solve
the problem of finding the schema if it's not listed in some list,
though); Although I prefer the way the SVG WG chose: have one NS URI
for all versions, then specify versions and profiles with attributes.

Tobi

-- 
http://www.pinkjuice.com/

Received on Sunday, 7 December 2003 08:24:05 UTC