On Saturday, December 6, 2003, 11:39:50 AM, Tobias wrote:

TR> Hi

TR> 1. SVG 1.1 RNG

TR> In
TR> there is
TR> "The contents of the 'metadata' should be elements from other XML
TR> namespaces"
TR> but
TR> has
TR>   <define name="SVG.metadata.content">
TR>     <text/>
TR>   </define>

TR> This means that the example provided in 21.3

TR>   <metadata>
TR>     <rdf:RDF [...]

TR> and all other SVGs of this type are invalid in respect to the above
TR> RNG, if I'm not missing something.

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)

You would need to write your own RNG for the other namespaces, then
write an RNG for your chosen namespace mix which imports the SVG one
and your other ones. This is a lot easier than with DTDs because RNG
does really understand namespaces rather than faking them up.

Now, what I said above is true for namespaces in general. For RDF,
where the designers concentrate entirely on the data model and seem
pretty indifferent to which of the various syntaxes are used, writing
 a DD or Schema for RDF is not really possible.

 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> Is the 1.1 RNG currently being actively developed?

Not recently, but it should be.

TR> I didn't yet get any replies to

Hmm, your svg seems to be correct and the relevant bit of the rng
seems correct also

 <define name="SVG.font.content">
      <ref name="SVG.Description.class"/>
    <ref name="font-face"/>
    <ref name="missing-glyph"/>
        <ref name="glyph"/>
        <ref name="hkern"/>
        <ref name="vkern"/>

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

TR> (there is a zip now, thanks,

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' ;-) I also located a DTD, added it in
the directory above,and added an xml:lang to the common attributes.
Although it doesn't cover the annotation elements yet.

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.

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. Equally, if you find more bugs, please report them (or indeed,
correct the RNGs and mail them in, if you get a burst of enthusiasm).

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?

TR> As Chris wrote in
TR> "Having an official SVG 1.1 RNG schema would certainly help in
TR> consistency of reference."

Ok, you are asking that they be normative, not that they be created.

TR> 3. Normative

TR> No matter if the main schema is maintained in RNG or in some other
TR> schema lang (eg a custom superset), it woud be great to have normative
TR> RNGs (at least for 1.2+), for various reasons such as those decribed
TR> in
TR> and
TR> etc etc

TR> When I get an error message it's tedious to find out if the error is
TR> in the SVG, the RNG, or in the validator.

I agree, although that will happen as they are developed.  Once they
are debugged you only need to decide if its the SVG or the validator,
and it becomes less and less likely to be the latter.

TR> If the RNG would be
TR> complete, correct, and ideally normative, the task would be greatly
TR> simplified: a bug report could be quickly submitted to the validator's
TR> project if the SVG is valid.


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.
Apparently people validate to different schemas at different times.

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?

TR>  Here's what the catalog looks like:

TR> <catalog xmlns="" version="0.1">

TR>   <language>
TR>     <xpath>
TR> namespace-uri(/*)=''
TR> and (
TR> /*/@version='1.0'
TR> or /*/@version='1.1'
TR> or not(/*/@version)
TR> )
TR> and
TR> not(/*/@baseProfile)
TR>     </xpath>
TR>     <local-schema>
TR> /home/tobi/bulk/xml/schemas/svg/1_1/rng/svg11.rng
TR>     </local-schema>
TR>   </language>

TR>   <language>
TR>     <xpath>
TR> local-name(/*)='svg'
TR> and
TR> /*/@version='1.1'
TR> and
TR> /*/@baseProfile='tiny'
TR> and
TR> namespace-uri(/*)=''
TR>     </xpath>
TR>     <local-schema>
TR> /home/tobi/bulk/xml/schemas/svg/1_1/tiny/dtd/svg11-tiny-flat.dtd
TR>     </local-schema>
TR>   </language>

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


Received on Saturday, 6 December 2003 22:38:01 UTC