W3C home > Mailing lists > Public > www-svg@w3.org > December 2003

Re: SVG RNGs

From: Chris Lilley <chris@w3.org>
Date: Sun, 7 Dec 2003 14:54:39 +0100
Message-ID: <732116012.20031207145439@w3.org>
To: Tobias Reif <tobiasreif@pinkjuice.com>
Cc: www-svg@w3.org, mimasa@w3.org

On Sunday, December 7, 2003, 2:26:17 PM, Tobias wrote:

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

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

TR> This might be a start:

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

I agree that sort of structure is better. The current RNG just
reflects what the DTD says. The DTD says text because that is the only
option really for DTDs.

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

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

Any recommendations for editors that seem to work well?

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

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

TR> tobi ~/del $ xmllint --noout --relaxng
TR> ~/bulk/xml/schemas/svg/1_1/rng/svg11.rng vimxml.svg
TR> file:///home/tobi/bulk/xml/schemas/svg/1_1/dtd/svg11-flat.dtd:2278:

You are validating the dtd against the rng?

TR> validity warning : Attribute space of element style: already
TR> defined
TR>     type %ContentType.datatype; #REQUIRED
TR>     ^
TR> vimxml.svg:32: element font-face: Relax-NG validity error :
TR> Expecting an element desc, got nothing

Now that one has to be a bug. desc is part of SVG.Description.class
and its clearly enclosed in a zeroOrMore implying zero of them is
fine....

TR> vimxml.svg:32: element font-face: Relax-NG validity error :
TR> Element font-face failed to validate content
TR> vimxml.svg:25: element font: Relax-NG validity error :
TR> Expecting element font-face, got font
TR> vimxml.svg:25: element font: Relax-NG validity error :
TR> Element defs has extra content: font
TR> vimxml.svg:24: element defs: Relax-NG validity error :
TR> Expecting element use, got defs
TR> vimxml.svg fails to validate
TR> tobi ~/del $

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

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

There is also a multischema validator, converts everything into rng
internally by Sun
http://wwws.sun.com/software/xml/developers/multischema/

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

The DTD does not have to be downloaded anyway, since its the external
DTD subset and thus optional. I agree that some tools always try to
download the TD and fail if they can't get it.

TR> You could omit the DTD doctype declaration, and if you had it in there
TR> for validation you could use RNG instead

 You can use the RNG anyway, if you prefer, no?

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

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

I think that the xsi:schemaLocation does exactly that - suggests but
does not require. Mind you, in theory, so does a DOCTYPE

>> Ok so its an automated conditional catalog using Xpath. Neat. Which
>> bits can't you fix locally?

TR> Not all schemas require instances to specify their language in a
TR> sufficiently specific way. The SVG WG did a great job, a human or a
TR> software tool can always know which language an SVG document or
TR> fragment is written in: there's the namespace URI, the version
TR> attribute, and the baseProfile attribute (and defaults when some are
TR> absent). With other languages things are less specific: an XHTML
TR> document with no doctype declaration or an XHTML fragment (both in the
TR> XHTML 1 namespace) doesn't specify if it's written in XHTML 1.0
TR> Strict, Transitional, or in XHTML 1.1.

Ah, okay. Sounds like an architectural principle lurking in there
somewhere.

TR>  A DocBook 4- document is even
TR> more problematic (but 5+ might bring improvements): It's not in a
TR> namespace, and there is no information about the version being used
TR> (it might be specified in a doctype decl which is not available to
TR> tools such as XSLT).

Not being in a particular namespace is bad.

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

You might be able to get that information by dereferencing the
namespace URI, seeing if there is a RDDL document there, and
looking for a link to your preferred schema type.

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

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

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

Yes I think thats better too, so a viewer does not need to have a
collection of near-identical namespaces that  it recognises.


-- 
 Chris                            mailto:chris@w3.org
Received on Sunday, 7 December 2003 08:54:40 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:26 GMT