RE: RDDL draft 20010114

[Jason Diamond <jason@injektilo.org>]

Hi.

> I just went through an interesting little test of the draft.  I tried to
> validate it using rxp.  I copied the draft to my computer, and
> then the dtd.
> That didn't work - of course -  since the dtd's address is
> relative, and rxp
> couldn't find all the included fragments.  Then I added the rddl
> base url to
> the path in the DOCTYPE declaration so it read
> "http://www.openhealth.org/RDDL/rddl-xhtml.dtd".  Now rxp could find the
> pieces.

http://www.rddl.org/#ZIP points to an archive where you can download all of
the DTD files. It comes in very handy while debugging. Unfortunately,
Jonathan had to modify part of the XHTML DTD because it included a PI with a
colon in the target name (which is illegal according to XML-NAMES). My XML
parser was throwing up on that one PI which made processing the actual
document rather difficult. I've emailed www-html-editor about that but
haven't gotten a response yet.

> 2) Once the spec is complete and valid, it would be very nice to use it as
> part of any conformance requirements.  In other words, a conforming
> (validating) processor has to be able to validate a local copy of
> the spec,
> since it describes its own dtd!  You might have to tweak the rddl
> element for
> the dtd by adding an arcrole so that the processor can be sure
> what the dtd is
> for.

I love this!

> 3) Although rxp is reasonably fast, the validation process was
> pretty slow.
> The slowness seems to have been getting all the dtd pieces over
> the network.
> This highlights how important caching is going to be.  In turn,
> this says that
> rddl will have to work with cached resources.
>
> I'm not really up on caching issues.  Anyone who is, please help out here.
> What, if anything, needs to be included in rddl to have it work
> correctly with
> cached resources?

I'm running into the same thing. There's an inordinate amount of external
entities as part of the modularization DTD. I don't believe that RDDL has to
do anything specific to support caching. That's most likely up to the
specific implementations. For example, using Microsoft's XmlTextReader
parser, I can give it a custom XmlUrlResolver that checks a local cache for
entities based on their URIs. So the second time a specific URL is resolved,
the XmlTextReader would read it from the local filesystem rather than from
over the network.

Of course, it would be nice if the RDDL DTD could refer to the W3C's XHTML
DTD using an absolute URI. Due to the bad PI I mentioned above, however,
this would make developing my RDDL processor impossible for me.

Jason.