forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: DTD questions
Date Fri, 31 May 2002 21:55:49 GMT
David Crossley <crossley@indexgeo.com.au> wrote:
 > > [link vs jump]
 > I have been confused over these for ages. Steven, and then i,
 > tried to demonstrate the differences in the Forrest demo
 > document-v11.html ... Rather than try to express the differences
 > here, please look at the demo document.
 > http://www.krysalis.org/forrest/document-v11.html

Crashed my NS 4.74 :-(

 > Your ideas about their use are somewhat different,
 > but not orthogonal.

I cannot see much of a difference in the descriptions for
  <link href="contrib.html#cvshowto">
and
  <jump href="contrib.html" anchor="cvshowto">

Furthermore, it's hard to see why <jump> uses href+anchor
while <link> sticks both together into @href. I just can't see
what advantage splitting the base URL and the fragment identifier
into two attributes has. The disadvantage is quite obvious (the
huge <jump> processing template I posted, alternatively frequent
validation against the proper DTD).
Proposal: discard @anchor completely. Simply remove it from the
style sheet rather than reintroduce it into the DTD.

BTW there are some text FIXMEs there, followed by a nice
boxed <fixme> only a few lines later... :-)
  <fun>
   <p>(FIXME: Use &lt;fixme> instead of FIXME)</p>
   <fixme>Should have used &lt;fixme> for the above</fixme>
  </fun>

 > We should perhaps implement
 > your abovementioned validation routine via stylesheet until we
 > get thorough XML validation happening.
Hmm. I'm for two years in the XML+XSLT business, and believe me,
keeping DTDs up to date in a distributed environment is a nightmare.
Apart from this, neither DTD nor any schema language I examined so
far can really handle all constraints. I finally took the following
approach:
1. Put incoming documents in an "incoming" directory. They are already
    visible through the webserver for QA.
2. Validate the incoming docs against a somewhat general DTD. This
    ensures the next step wont blow completely and weeds out the worst
    problems (introduced by guys making "just a simple last minute fix"
    with a text editor). Move the validated docs to a "pre-production"
    tree.
3. Run a XSL transformation which checks the details and produces an
    error report. In particular, check complicated cross dependencies
    (if this is 'a', that should contain a <foo>), dead links across a
    set of documents (mostly because of misspellings), names that have
    to be unique across the set of documents and constraints for text
    values like URL formats. Empty result -> ok. This is time consuming
    and only run every once a while.
    Nice property of the error report: It is XML like everything else
    and can easily be viewed through the webserver with a browser.
4. Optional: Run another XSL transformation which inserts defaults for
    optional stuff and kills the DTD reference. Improves performance
    for documents where the DTD is larger and more complicated than the
    document itself.
    Generate system wide index files and some aggregated content at this
    point too.
5. Move the checked docs into the "production" tree.

 > Is the <connect> element still relevant?
I don't think so. It's been dropped from the DTD, and only
lurks in the style sheet. I propose to delete the template.

 > > [DTD hooks]
 > I am a bit lost on that - perhaps someone else can answer.

These are the customisation hooks, as seen in other large DTDs.
Example
   <!ENTITY % localblock "">
   <!ENTITY % block "(para|this-stuff|other-stuff %localblock;">
This allows other people to customise their DTD without editing
the .mod files:
   <!-- override localblock -->
   <!ENTITY % localblock "|custom-block">
   %document.mod;
The customised DTD now allows
   <section>
     <para>A custom block:</para>
     <custom-block/>
   </section>

Note that this mechanism allows easy customisation but somewhat runs
counter to modularisation, because the parameter entities providing
the hooks have to be overridden before they get their empty default,
and there is only one chance to override it.  If the FAQ DTD
introduces a FAQ-specific block element, there is no easy way to have
a HOWTO DTD which uses the faq.mod introducing its own specific block
element while keeping the faq specific block. Life sucks. As you
apparently are knowledgable with Relax NG, is there a way to solve
this problem there? I have some ideas how to tackle it using XSchema,
but it's not yet really satisfactory. Of course, this begs the
question: is there a problem that *needs* to be solved? The hooks seem
to be a bit - ahem - underutilised...

J.Pietschmann


Mime
View raw message