Subject: Re: API to formatters and grove engines From: Jean-Xavier Lotthé <mg068-3@xxxxxxxxxxxxxxx> Date: Tue, 01 Jul 1997 15:52:02 +0000 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: API to formatters and grove eng, Jean-Xavier Lotthé | Thread | Re: API to formatters and grove eng, James Clark |
Re: API to formatters and grove eng, Jean-Xavier Lotthé | Date | Administrivia, DSSSList Owner |
Month |