okey dokey...
I kind of already mentioned this idea before, but here're some more detailed thoughts
and explanations on it:
XML is ideally suited to represent hierarchical slices of very complex data for
exchange with other programs or display engines etc, but not necessarily to
efficiently store that extra complex data in its complete form. By "slices" I mean,
let me illustrate: suppose you have a 3D cube with 3 dimensional data in it, and you
want to be able to access any of that data. The final rendering of the data will be
2D (say for a flat picture), so you can take many different views of that data, all
different, but none of them will completely (and efficiently!!) store that data,
without duplicating your whole 2D spatial grid a bazillion times for that 3rd
dimension! And even then diagonal/rotated slices could only be approximated from that
source data or else the whole thing done again another bazillion times for each
possible rotation! (Rotation of the slice being almost like a 4th dimension.)
Ok, that's the visual/mathematical idea, now how it works with us: If we **need**
book/chapter/verse granularity for a particular end user application, it's best to
give that app an XML representation that does exactly that, no more and no less. No
need for it to bother with verb tenses and historical contexts and fancy quoting
dealies, etc, unless the app actually needs it and can handle it. Likewise, suppose
the application is something that reads the text aloud using some computer synthesized
voices, you may want to do book/chapter & quote granularity, for instance, because
that's what you need in that case. Using the information about who's saying what it
could say it using different voice sounds/accents, and give the ability to jump to any
chapter but not any verse. Another application that does complicated word analysis
(i.e. verbs/nouns/predicates/tenses/etc) would want much more detailed info about each
individual word, and it may require book/paragraph/sentence g!
ranularity above the word level **not** chapter/verse, even though it may still want
chapter/verse markers (i.e. this time not part of the nested tree structure) so it can
give visual indicators to the end user where they are.
Above I've listed 3 different example slice types, and they do not necessarily mix
well together in one single cohesive rigid XML format, but each **does** work quite
well as its own independent XML representation of the same general data underneath.
So the question is.... are you trying to define one single rigid
everything-for-everyone-forever XML format or a more modular extensible approach that
can represent it in any way needed at the moment? You can probably see I'd very much
prefer the latter ;o) Let the engine/library decide what it wants to use for
ultimate storage underneath, it may not even be XML (and yet it may be XML if it
wants, just that it may instead be some custom binary/etc format for speed and/or
space optimization on disk/memory/etc).
But if the library can transform this stored data into whatever XML format is required
on the fly, then that would be really cool, as the end user app would only need light
already-built robust tools to mine the data out that it needs since the "picture" of
the data it's getting is already suited to its needs. For instance, a simple XSLT
could be employed to create any HTML rendition you want.
The only drawback might be a way of the app declaring to the library what format it
needs, perhaps pass it a DTD or something? Xpointer and Xpath don't seem suitable for
that... Just that a DTD seems overkill to me, but perhaps not if the standard is kept
simple... but the app also should be passing the library reference ranges and search
queries, so... hmm
Anyway, that's where I'm at with this idea right now, you can see in the last
paragraph that the idea isn't complete yet, but I think it's enough of a start that it
deserves merit.
If this idea doesn't make it into SWORD, it will likely put it into my own existing
side project eventually anyway, sample URL was sent earlier. Probably with my own
evolving XML spec if others don't agree with me--not that doing my own is bad, it's a
natural part of the evolution of these things for someone to jump in and try it first,
and then if it works well for others to come on board and eventually for a better
designed spec to be agreed upon that is designed by the community at large. That's
especially true for radical things that go against tradition! ;o)
Dave
At 05:07 PM 8/30/2001 -0700, Troy A. Griffitts wrote:
> But, since you seem to be so xml proper :) ... WE NEED YOUR
>(everyone's) FEEDBACK as to what tags should go into an XML markup
>standard.
