Re: API to formatters and grove engines

[Jean-Xavier Lotthé <mg068-3@xxxxxxxxxxxxxxx>]

James wrote:
>There are two things that are needed.  The first is to add the capability
>to Jade to format just a specific element instead of the whole document as
>now.  There are two ways you can do this.  One is simply to apply the
>construction rule for that particular element: that will work if the style
>sheet has been written with the intention of just formatting specific
>elements.

Having independant, non-related to each other ARTICLES in my SGML document,
this was indeed the first solution I thought about. I would then have had an
'articles.dsl' file dedicated to formatting these independant articles. This
solution works very well if you designed your SGML document as a 'library'
simply containing self-sufficient ARTICLES, which is actually my case. One
may also think that such a style sheet could be more simple and easier to
modify by the end user. This solution would therefore satisfy my immediate need.

>The other way is to try to produce for the element that is being
>formatted the same output that would be produced when that element is
>formatted as part of the complete document.  This is harder to implement
>but more useful in some situations.

This is true that this other solution may be more adapted if you want to
output a CHAPTER of an SGML encoded BOOK. In this case, you probably would
need the chapter number, page numbers, page header with the book title
enclosed and so on. The CHAPTER not being self-sufficient, you would need
some reference to the rest of the BOOK.
Another case would be when you have to deal with hypertext links to other
elements in the SGML document. I can see an illustration of this if you had
numerous quality PROCEDURES in a quality MANUAL. These PROCEDURES often
relate or make reference to each other. The referenced PROCEDURE's NAME that
should appear in the RTF output is often not included in the PROCEDURE
itself: it is the result of a link to an external PROCEDURE's ID that
returns it's NAME.

I therefore understand the question of formatting an element 'as part of a
complete SGML document' as double-sided:
        - items related to the sequential formatted output, such as page
numbers. I can easily think that this is harder to implement and, in any
way, forces into formatting the entire document. It brings with it the
convenience of being able to output just one CHAPTER of a BOOK, without
loosing consistency with the rest of the BOOK in terms of page numbers.
        - items related to elements outside the element you want to output,
such as a NAME of a referenced PROCEDURE. The question here is not to format
the entire SGML document but rather to allow a style sheet the access to an
item not in the scope of the node it is supposed to format. In more simple
words, when formatting a specific node, would I still have access to
siblings or parents ?

Even if these questions lay outside of my immediate need, they may be, as
you said earlier, very useful in some situations.


>The second thing that is needed is to be able to avoid having to reparse
>the entire document for each formatting job.

Yes, definitely.

>I can see two approaches to this:
>1. Implement a persistent store for groves.  The OLE automation grove
>interface and Jade are both built on top of the same interface, so if this
>was implemented for one, it would be available to both.

You wrote ealier:
>The approach I would take
>would be to have a separate program that built an on-disk representation of
>the grove.   Jade would access this just by mmap-ing in the disk file.

I think this idea is excellent when, as you mentionned, you work more than
once on an unchanged document. That could be the case of a SGML document on
a cd-rom. The advantage of such a solution is that it would be platform
independant and that user would directly access the document without having
to parse it first. I believe SGML database applications extensively use this
method in case of unchanged documents. This solution would probably satisfy
my immediate need.


>2. Provide an OLE automation interface to the style engine.  This would
>allow you to apply multiple format operations on the in-memory document.

This is the solution I first thought about as well as my favourite. Although
it implies an initial parsing (which by the way could be avoided in the case
of an unchanged document if the two approaches were made available), it
allows the SGML document administrator to freely update his/her document
without having to ship a new 'grove representation' file. This dynamic grove
representation could be very useful when you want to update your SGML
library with new ARTICLES.
As I am already working with Jade's GroveBuilder OLE automation interface, I
would find it very elegant to access the style engine through the same method.
Furthermore though this is pure speculation and I don't need it for the time
being, I wonder if this method would not simplify the access to nodes
outside the specific node you want to output. Having the grove in memory,
could a 'PROCEDURE.DSL' file make reference to a sibling PROCEDURE's NAME ?

I see these two solutions as complementary, though I'd prefer by far the OLE
automation.


I don't quite realize the amount of work it would need to make these
extensions available. Pardon me, James, if I seem to put you under pressure,
you know that's not my intention. I was relieved to read David's positive
attention to our work. I'd be delighted if this work may answer *human*
needs rather than pure business ones.

By the way, you mentionned earlier the possibility to add some higher-level
SDQL like functions to the OLE automation interface. That would really be
fantastic !

Best regards from the poorly babbling french list member
Xavier


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist