Frontier as a scalable XML repository (was Re: Is XML dead already or what?)

[W. Eliot Kimber]

At 05:43 PM 1/30/99 -0800, Dave Winer wrote:
>>>4. It's an object database but all I see are tables. This confuses me
>because I expect tables to be for relational databases and objects to be
>for object databases.
>
>Tables are like hashes in Perl, except they're virtual, don't need to be
>managed, and are tightly integrated with the scripting language.
>
>We give you a choice of scripting language, on Windows you can use Python,
>or Perl, or JavaScript or VB Script, because we wired into Active Scripting
>Host, it's just not as deeply integrated as our own language, it can't be,
>yet, so there are still things that are easier/faster in Frontier's
>internal language, but I expect over time, with help from Microsoft that
>this will be less true in the future. We don't fight syntax choice battles,
>learned that lesson a long time ago.

That's good--but does that apply to templates as well? 

Let me reiterate that I just went briefly through the tutorial, so I've
likely missed important concepts. But part of the test of any new tool is
how closely it matches my existing mental model of how a particular task
should be modeled and supported in a computer. So far Frontier has not
matched very well, or at least not appeared to. This doesn't mean there's
necessarily anything wrong with Frontier--after all, my personal models are
often very idiosyncratic and there are always a variety of reasonable
models for any given task.  I'm simply observing a mismatch and reporting
that, as a result, it is difficult for me to see how Frontier can be
applied to the types of tasks I want to perform.

I suspect that this is in large part because the marketing focus of
Frontier is on its use as a Web content server and not as a generic
document management system. If the marketing focus was on the latter, I'm
sure the application would have been made clearer.

In other words, I expected to see (and wanted to see) a document management
system and instead saw a Web site server.  

Now that I think about it, I think the difference comes down to simply what
is the initial input to the "serve some data" process: the data to be
served or the script that generates the data.

In my normal model, the data comes first, so I would expect to give a
process some data (e.g., a document) and then apply a script to it.  The
Frontier model, as near as I can tell, is to start with the script and let
it get (or generate) the data.  Nothing wrong with this second model, but
it's not the one I'm used to. 

Why am I used to my model? Because that's the way a document-centric system
works. You start with a document and then process it.  

I note that Michael Lawley's XSL support for Frontier provides exactly this
model: he provides a stub template that effectively runs an XSL script
against a document. Which begs the question: why did he have to create the
stub template--why doesn't Frontier have a "apply script to document"
facility built in?

>Some of your other conclusions, esp the most broad ones, are not true. 

More concrete details please. Remember that my conclusions were based on an
initial, and brief, investigation of the tool, so they are likely to be
incorrect, or at least inaccurate.  Part of this exercise is to determine
how accurate a picture of Frontier the initial marketing information
provides. This is the way I must evaluate most tools: spend 1/2 hour poking
at them and reading the available info. If they pass that gate, then maybe
invest some real time in trying to do something realistic.  There are too
many tools to spend too much time with any one tool.  It means that some
good tools that are simply poorly presented will be missed, but it means
that a lot of bad or inapplicable tools will be quickly eliminated.

                                                                      Many
>people use Frontier without writing scripts. 

Perhaps I'm using the wrong terminology. I think I mean "template" (the
"wp" files) when I'm saying "script", now that I think about it. 

                                            I agree with you about what
>integrators need, and many of the things you ask for are available from
>other sources, or are part of the next release. You can get a preview of
>the next release on this site:

The old "it's in the next release" answer... :-)  After spending as many
years as I have hearing this from vendors, it's very hard not to be cynical
about it. 

>http://developers.userland.com/
>
>Re processing your SGML docs, we have native support for XML, not SGML. Not
>sure we can help you with SGML. The site has a section on Frontier 5 and
>XML, not sure if you came across it. If not, please check it out:

I read it--it didn't tell me much, and it didn't make it clear how Frontier
helps me manage XML docs (as opposed to how one might serve the XML docs as
HTML, which would be through scripts and/or templates (right?)).

I'm not trying to be difficult or argumentative--just trying to understand
what a particular tool does.  But please understand my potential for
frustration and my starting point as an integrator and evaluator of tools:
I want to be able to spend the least amount of time getting the most
accurate picture of a tool possible. Therefore, I want the marketing
information to be clear and informative. I want the demo to get me doing
things I want to do as quickly and as clearly as possible.  Because of my
severe time presure, I will cut and run at the first major hurdle to making
the demo work or getting an answer to a technical question, simply because
there are always more tools to evaluate.

So, using my experience with Frontier as an example only (only because
David was brave enough and cares enough about his tool to ask us to
evaluate it in good faith, which I hope I'm doing), here's what I've got so
far:

1. David says "hey, this tool really does these things you want, even
though it may not be obvious from how we market it."
2. I say "Ok, I'll take a look--I can always use another tool in the
toolkit, and doc managers are sorely needed."
3. I go to the web site. Looks pretty good, informative, easy to navigate,
always a good sign. I can download an eval. Super.
4. I download the eval, read the readme, start it up. It works. No
intrusive install process. No reboot. Even better. So far the Frontier
people have impressed me as not only not being idiots, but as being pretty
clever. Another good sign. Press on.
5. I invest the time in reading the tutorial. Chatty style is a little
annoying, but probably appropriate for their primary audience, which isn't
hardnosed techies who just want to do something. I follow the steps--they
work. No obvious difficulties making the thing work or seeing how the
system is put together.

At this point, so far so good.  But

- It's still not clear to me how this is anything more than yet another way
to do CGI scripts.
- The exposing of the innards, while encouraging to the Unix geek part of
me, is off putting to the Windows user part of me, who wants the parts I'm
supposed to touch to be clearly delineated from the parts I'm not.  The
Frontier tutorial writer realizes this and puts in a warning about not
touching stuff, but that doesn't help me understand the tool by reading the
user interface.  This suggests that the tool itself is guru territory.
- From the tutorial I see a process driven by template doucments in a
unique syntax. Not a good sign--I want standardized or well-known syntaxes
wherever possible. Also a point at which my model and Frontier's apparent
model diverge.

6. I poke around in the online docs some more (more positive points: all
the docs on the website and easily downloadable).  It's clear that there's
more going on here, but the docs don't really help me understand the doc
management side of the tool, if there is one.  From the turorial, I
understand that I can't just suck in my existing Web site and go--that I
have to do more work. I don't like that--I want to start with a new tool
from where I am now and take advantage of new features only as I need them
or have time to apply them.  Even a moderate cost of entry can be
prohibitive unless the return on investment is significant.

I run out of time (actually, a real work problem came to the fore that I
had to solve--but that's my day, never enough time to play with new toys).

Conclusion: strong marks on basic implementation and packaging. Strong
marks on eval friendliness.  Implementors are clearly not idiots (remember:
implementors who are not idiots is a very small set, at least in my world
view).  Still not clear how to apply tool as an XML document manager. 

My person action: Classify as "worthy of further consideration given
additional information and/or possitive feedback from other evaluators". Do
not delete from hard disk just yet.

My response to clients who ask my opinion: Appears to be useful as a Web
site system. Worth taking the time to evaluate. Cannot attest to
capabilities with respect to scale or performance because I haven't done
anything real with it myself.

My suggestion to Frontier at this point would be:

1. Enhance the marketing info to provide a "how to use Frontier as a
document manager" tutorial.
2. Provide a bit more handholding in the user interface, at least as a demo
add-on.  There seems to be a mismatch between the target user audience
(gurus) and the audience the tutorial is pitched to (non-gurus).

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)