[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: [FrameSGML] Re: Database-Style Queries in structured FM

Note: This response to a posting on the FrameSGML list, has been cross-posted to the FrameUsers and Free Framers list.
Thanks for the moral support.
My complaint about one-purpose FDK clients and Framescripts is exactly that--they are one purpose. The Developer builds an application to satisfy a spec from a particular customer, or develops the application from what he/she believes is a universal spec that will fulfill a widespread need. Either way, the application is built according to a set of assumptions, and the assumptions themselves tend to limit the application's universality. The approach I advocate would produce FDK client or FrameScript applications which provide a simple meta-meta-language that gives the end user the power to create his/her own applications.

FrameMaker's Find/Change capability is a perfect example of the limitations of the typical approach used in developing an FDK client or FrameScript application. Find/Change's power was (more or less) sufficient for most unstructured docs. But it's grossly deficient for structured FM, which came after the Find/Change feature had already been developed. The limited capabilities added for structured docs were an afterthought, and, most probably, the addition of more capabilities would have required massive modifications to the existing code.

The syntax of the meta-language used in the examples I offered is quite similar to that employed in a product I use all the time--UniMerge for database publishing. There are, I believe, thousands of users of this product, and most of them have no programming experience of any kind. UniMerge works with FrameMaker, Ventura, and Interleaf. It comes with an excellent PRINTED user manual (120 pages), but only 18 pages are required to describe the command keywords and the syntax of the expressions in which they can be used. This command language, although quite simple, is extremely powerful. So powerful that, in the 10 years I've been using UniMerge, I've rarely run across a database publishing requirement that couldn't be mastered with UniMerge.

Hi Dan,

You wrote:

--- In FrameSGML@xxxxxxxxxxxxxxx, DW Emory <danemory@xxxx> wrote:
> The most fundamental advantage of structured documents is the
ability to
> parse them into their constituent components for storage in a
relational or
> object-oriented database, where complex queries can be issued to
> and or modify, selected data.
> But a structured FrameMaker document or book is also a searchable
> which could be searched using queries similar to those used in a

While I disagree partially (but not completely) with your search/set
scripting proposal, I agree 100% with your opening statements.  I
think you are right on track with your assessment of a structured FM
document as a searchable database.  And, as you allude to, the only
limitations of this "database" is your ability to query and manage
data. Unfortunately, though, these limitations are critical, and
really prevents you from using a doc as a database.  But you know
this... hence the proposals/requests in your post.

Structural metadata in an FM file is as parsable and manageable as
any text markup format... we've shown that somewhat with our recently-
released Sourcerer plugin.  But I'm not writing to plug Sourcerer...
I just think it is a good example of the possibilities of metadata
within structured Frame, without ever having to leave Frame.  I'm
surprised that there isn't more progress in this direction already,
because in many cases, it is so much easier to manage content right
in front of you, in a WYSIWYG environment, rather than using
middleman tools like databases or XML/XSLT.  Now, I don't mean to
bash these tools... they are indispensible and certainly have their
place.  I do think, though, that they may be a bit of overkill for
certain needs, but they get used because they are the only choice.
But, I also believe that this is only because Frame hasn't been
taught to do the things you have identified.

There is work ongoing in this direction, and I'd encourage you to
stay tuned. For now, I'd just like to commend your forward vision...
it is envigorating to see people thinking outside the box.  We've
disagreed in the past about methodology, and maybe always will, but I
think that theoretically you are on the right path, and eventually
more people will begin to understand and accept where you are coming

FrameMaker/FrameMaker+SGML Document Design & Database Publishing DW Emory <danemory@xxxxxxxxxxxxxxxxxx>

** To unsubscribe, send a message to majordomo@xxxxxxxxx ** ** with "unsubscribe framers" (no quotes) in the body. **