Lists Home |
Date Index |
- From: firstname.lastname@example.org
- To: email@example.com
- Date: 27 Nov 99 08:26:02 -0500
At the risk of sounding pretentious, contentious, or even both....
> To take one example, imagine that you're managing a custom publishing
Not hard to imagine from here; I publish my own zine, and have had to assemble my
own funky way of managing an ever-growing site singlehandedly with minimal effort.
> The standard non-SGML/XML way to do this is to assemble fairly large components
> (sections, chapters, or whatever) using relational databases (where the components are
> blobs) and/or document-management systems (where the components are smaller
> documents), and you've probably bought an off-the-shelf package that does this.
I'm using document management, if I understand your categories properly. Specifically,
each episode of a given column is its own file, and I use a template processor to marry
these data files to common templates. This produces a file set that is ready for upload,
and when a given file is requested, the server does some more processing at that time.
The template processor (htp) is a small piece of freeware; the server processor is
available through my ISP's hosting service. Still, I'm pretty much with you.
> If (say) you decide to use XML for the assembly templates to make those templates
> system-independent (and reuse them elsewhere in the system), you have only a
> relatively small integration problem on your hands.
I might question that "relatively small" bit. I would find it a large challenge to migrate
from htp to an XML-based system without losing anything; the big advantage to what
I've got is that I can set up the htp->XHTML "transformation" <g> to transform valid
HTML tags into optimized XHTML constructs. For instance, <center> can become
<div align="center"> or even <div style="align: center;"> almost as quickly as I can
envision the transformation. OTOH, trying to recast the htp data files into full-fledged
XML fragments would be a much more daunting task. In fact, it'd be a lot like the
complexity you go on to describe, except more so:
> But ... and here's the catch ... you realize that with XML it is possible to customize
> much further than you already are. You read books and articles and find out that you
> can customize at the phrase or even the word level, like this (to take a silly example):
> <p>What <choice-group><choice loc="CA">colour</choice>
> <choice loc="US">color</choice></choice-group> is that?</p>
Ultimately, that's a trivial example, and there are better ways (or at least easier ones) to
do it. For instance, define your own "color" entity which gets shifted on the fly
according to location, and this could become:
<p>What &color; is that?</p>
Yes, that has the disadvantage of being something of a hack and requiring a growing
library of international terms, but IMO, this is more than balanced by the increased
legibility and decreased footprint of the document.
> Wow! That's a lot better than the blunt instrument that you have now,
> so you run ahead an invest a few $100K in an XML-aware DMS that may or
> may not scale to your user base and another $500K for a phase-one
> implementation from an XML consulting house, etc., etc., and suddenly
> you decide that XML is very expensive.
This is where you make your key logical error. The database doesn't need to know
about what's in an element; I currently use Access 97 to handle iHTML script fragments,
and Access is blissfully ignorant of the uses I'm putting it to. In fact, if Access was
bright enough to try making sense of the data I'm storing in there, it could seriously
screw me over by munging that data. The hard part of making a library of text granular
is in going through that library and converting that data accordingly - making the entity
(or definition) library itself is a snap by comparison. For instance, if you remember my
rants about the Q element, setting up the htp definition was only hard because I had to
manually scout out the support levels for that tag in various browsers. Implementing the
definition, on the other hand, requires a lot of tedious work - specifically, poring through
the various articles and re-marking the quotes accordingly. There's no shortcut for that,
no matter what system I use - but since the average user won't notice a big difference,
there's no real time pressure. I can make sure that new articles are marked properly as
they come in, spread the archive re-marking task out over time (since the archives don't
get a lot of hits), and the load becomes easier.
> But you're wrong -- it's not XML that's expensive; it's the kind of
> custom publishing that you're trying to do.
And I say that you're still half-wrong - it's not that kind of custom publishing that's
expensive, but the way you're going about it. Your complication requires no change of
software, but it does incur a new burden of tedious re-marking of old data. Spread that
out a bit (because after all, unchanged documents are not unusable - they're just not
optimal yet, and they're still the same documents you had up pre-change) and that
burden becomes more of an inconvenience. If I were to discipline myself to read
through twenty source documents a day, I'd be done with my re-marking in a couple of
weeks. Five documents a day, and it's two months - which still isn't that bad.
> It's easy enough to demo this sort of thing on my notebook with ten sample
> documents, a browser and a couple of Perl scripts, but it turns out to be very hard
> and expensive to implement in a high-volume, high-performance environment.
And I say, not necessarily. Take the lexical transformation above - wire the list of terms
up to a grep bot, and it doesn't much matter whether you're handling ten documents or
ten thousand. (Especially with modern CPU speeds!) After a template change, I can
generate my 570-page site in a couple of minutes at most. Sure, the upload will take a
half-hour to 45 minutes, but I can set that to run while I'm asleep or at work, and that's
not really a function of my development environment. (Case in point - the other day, I
changed the XHTML definition set to conform to the new Working Draft's !DOCTYPE
and namespace revisions. The generation took a couple of minutes, and the files went
up last night as a weekly update. The transfer broke down near the tail end, so I had to
manually upload the remaining files this morning - but still, I saved about 35 minutes of
upload tedium.) Overall, my site is no harder to administrate now than it was two years
ago - the only rough spot is when I decide to do a transformation that affects the actual
data files (a retrofit), and that's just tedious...not difficult, and not expensive.
Rev. Robert L. Hood | http://rev-bob.gotc.com/
Get Off The Cross! | http://www.gotc.com/
Download NeoPlanet at http://www.neoplanet.com
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)