- From: Chris Lilley <chris@w3.org>
- Date: Sun, 7 Dec 2003 14:54:39 +0100
- 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 UTC