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

[DW Emory <danemory@xxxxxxxxxxxxxxxxxx>]

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
> retrieve,
> > and or modify, selected data.
> >
> > But a structured FrameMaker document or book is also a searchable
> database
> > which could be searched using queries similar to those used in a
> database.
>
> 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
> from.

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.   **