cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

File Entities

unknown1
1-Newbie

File Entities

I have a document that contains about 150 file entities and not much
more. Everytime I bring up the document it takes about a half hour
even with completeness checking turned off. Does anyone know why it is
taking so long to bring up the document? Is there a way to bring the
file up quicker. Any suggestions would be greatly appreciated. I am
currently using Adept Editor 7.0.
10 REPLIES 10

At 04:35 PM 4/8/98 -0400, John P Baklayan wrote:
>I have a document that contains about 150 file entities and not much
>more. Everytime I bring up the document it takes about a half hour
>even with completeness checking turned off. Does anyone know why it is
>taking so long to bring up the document? Is there a way to bring the
>file up quicker. Any suggestions would be greatly appreciated. I am
>currently using Adept Editor 7.0.

Don't use file entities.

External text entities are bad and should be avoided as a general rule.
See the paper I presented at SGML '96, "Re-Usable SGML: Why I Demand
SUBDOC" at "http://www.isogen.com/papers/subdoc.html". You will also find
a variety of tools that demonstrate resolving subdocument references to
enable production of a single "compound document" at
"http://www.isogen.com/demos/tools.html", including Perl scripts and Jade
specs.

Arbortext has done a very good job of enhancing ADEPT's support for
subdocuments in 7.0, for which I am very thankful.

Here is a simple command file that lets you double click on subdoc
references and open the document in a new editing window [note: this
command file was also created in 1996, in part to demonstrate the
principles in the paper cited above, but also for my own use at the time]:

--- cut here ---
#---------------------------------------------
# Edit subdocument: enables easy launching of subdocument entities from
# elements that reference them. Gives same function as double clicking
# on file entity references.
#
# NOTE: subdoc entity reference must be from a element.
#
#---------------------------------------------
package edit_subdoc
function open_doc() {};
function edit_subdoc() {};
function setup_edit_popup() {};

function setup_edit_popup() {
if (menu_exists(":Edit")) {
if (!menu_exists(":Edit.Edit subdoc")) {
menu_add :Edit. "Edit subdoc" \
-cmd {edit_subdoc::edit_subdoc(oid_current_tag())}
}
}
}

function edit_subdoc(oid = oid_current_tag()) {
local $path;
local $current_path = dirname(doc_path(current_doc()))
oid_attr_list($oid, atts);
for ($attname in atts) {
if (oid_attr_type($oid, $attname) == "ENTITY") {
$entname = oid_attr($oid, $attname);
$enttype = entity_type($entname);
tag_attrs('&' . $entname, entatts);

$path = tag_attr_value('&' . $entname,'Pathname');
$pubid = tag_attr_value('&' . $entname, 'Publicname');
if (path == ") { # See if we can resolve publid ID
$path = public_id_path($pubid, ")
}
if ($path == ") { # Couldn't get a path
response("Edit subdoc: Could not generate a filename for entity
$entname,\n" .\
"with public ID "$pubid".")
} else {
if (dirname($path) == ") { # just a filename)
$path = $current_path . $path
}
if ($enttype == "file") { # Must be a subdoc entity, no other
type
# of file entity allowed from ENTITY
atts
# message "Opening subdocument entity $entname, at location
$path...";
edit -newwindow $path

# open_doc($path, "Subdocument $path of $filename");
}
if ($enttype == "graphic") { # Must check to see if it's
notation is SGML
$dcn = toupper(tag_attr_value('&' . $entname,'Notation'));
if ($dcn != "SGML") {
message "Referenced entity is not an SGML document
entity--cannot open it.";
} else {
edit_subdoc::open_doc($path, "Document $path
referenced from $filename");
}
}
}
}
}
}

function open_doc(path, title) {
local $doc_oid;
local $docwin;
local openflags = 2 | 4 | 16 | 32
$doc_oid = doc_open($path, $openflags);
if ($doc_oid < 1) { # File doesn't exist or path not set correctly
message "Problem opening entity at location $path.";
} else { # load it up
$winflags = 1 | 2 | 4 | 8 | 16 | 32;
$docwin = doc_window($doc_oid);
if ($docwin == "-1") { # Document not yet open
$docwin = window_create('edit', $winflags , $doc_oid);
window_set($docwin, 'title', $title);
current_doc($doc_oid)
menu_load
local cmd = "source " . doc_type_dir($doc_oid) . "\" .
doc_type($doc_oid) . ".cmd"
exec $cmd
} else {
message "doc $doc_oid already open"
}

doc_show($doc_oid, $docwin);
current_doc($doc_oid)
}
}

alias edit_subdoc edit_subdoc::edit_subdoc()
edit_subdoc::setup_edit_popup()

--- cut here ---

Cheers,

E.
--

W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004
www.isogen.com
</address>

> From: "W. Eliot Kimber"
> Subject: Re: File Entities
>
>

> > From: "W. Eliot Kimber"
> > Subject: Re: File Entities
> >
> >

Mike Desrosiers asked:
| When creating a file entity, the parent document's entity declarations
| (both file and text entity declarations) appear to get inherited by
| the new file. Is there a way of "turning this off"?

I have not personally looked at ADEPT 7.0 yet, but the answer in 6.0 or
earlier versions is no. This is a problem that I believe Arbortext has
been looking at, because it is, in fact, much more pernicious than your
description. These declarations can 'grow' and 'infect' an incredible
array of files in areas where they were not meant to go. And cleaning them
up is very painful (you have to find every inappropriate declaration from
a related set of files and remove all of them). It also affects system
response when you try to define more entities, change them, or insert
them...

To give you an example of accidental infection:

A writer opens a file and decides to copy a section from another file not
related to the current one...she opens the second file. At this point,
ADEPT
tries to even out the entities between both files so everything gets
copied into each other -- thus infecting both files with inappropriate
entity declarations.

This scenario is especially pernicious if you have files that are referred
to in multiple documents (which we do). If one of the shared files gets
infected, then all the shared files eventually get infected as well as
every document that refers to any of them. (Can you tell that I am REALLY
tired of catching this problem and trying to de-infect our documents? 🙂

The last I heard, Arbortext was looking at this, but I haven't seen or
heard
whether a solution is even proposed, much less implemented. Could someone
from
Arbortext comment on this???

Sara

At 09:48 AM 4/10/98 -0400, Sara.Mitchell@smed.com wrote:

>This scenario is especially pernicious if you have files that are referred
>to in multiple documents (which we do). If one of the shared files gets
>infected, then all the shared files eventually get infected as well as
>every document that refers to any of them. (Can you tell that I am REALLY
>tired of catching this problem and trying to de-infect our documents? 🙂

Repeat after me:

External text entities are not reusable objects...
External text entities are not reusable objects...
External text entities are not reusable objects...

Any attempt to try to make them into reusable objects will lead to pain.

Cheers,

E.
--

W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004
www.isogen.com
</address>

Hello James,

There are several ways to accomplish this:

- If you want to reuse sections as such, including their titles, you need
to store the whole section in an entity. If you do this, *either* your DTD
has to accept (say) Sect2 in places where it was accepting other levels
(which is ugly and undesirable), *or* you need to use generic nesting
Section elements that work at any level. DocBook has such a thing, and our
latest bundled FOSIs support it.

- Alternatively, you can design your DTD differently to recognize the
"module" structures that you intend to reuse. A good example of this is
DocBook RefEntry elements, which attach at several different places in the
hierarchy, and have their own internal structure that floats along with
them. If you have a highly structured reuse methodology, adding something
like a Module element (with ModuleSec inside) could make sense for you.

- If you want to reuse the section content but be able to change the
section title, then storing just the content in an entity (as you
suggested) would work.

- There are other, more esoteric mechanisms for achieving reuse, such as
SGML's SUBDOC feature. However, if XML conformance is important to you,
note that SUBDOC are unsupported in XML (and XML doesn't have an analog for
it -- yet, anyway).

Hope this helps,

Eve

Dombrowski, James said:
> One possible solution is to save only the "content" to a file entity,
> without the hierarchical section tags or title elements. This would allow us
> to import the content into any hierarchical container, regardless if it is a
> Sect1, Sect2 or Sect3. Does this make sense? What is your method of using
> file entities for reuse of information in multiple documents (especially
> where the hierarchy can change from one document to the next)?

It sounds to me like the DocBook DTD isn't suited for your application.
Using numbered section elements makes reuse very difficult, as you have
experienced.

I would suggest using an element that recursively allows itself in the
content model. Here's a simple example:




Each section allows a section within it, so you never have to worry if the
element is valid (as long as it is somewhere within the chapter). Use
context to determine how to format the element.

Steve Cogorno
Sun Microsystems

At 10:40 AM 10/18/99 -0800, Steve Cogorno wrote:
>It sounds to me like the DocBook DTD isn't suited for your application.
>Using numbered section elements makes reuse very difficult, as you have
>experienced.

James is in luck; a generic Section element is a new(ish) feature of DocBook.

>I would suggest using an element that recursively allows itself in the
>content model. Here's a simple example:
>
>
>
>
>Each section allows a section within it, so you never have to worry if the
>element is valid (as long as it is somewhere within the chapter). Use
>context to determine how to format the element.

Be careful, though -- you probably don't want (title, (section|para)+), but
rather (title, para*, section*). The paragraphs in between sections will
be orphaned.

Eve

Eve,

Thanks for the quick response. Your first paragraph mentions "generic
nesting Section elements that work at any level", but you don't say
specifically which ones. Can you eleborate? Thanks.

At 02:01 PM 10/18/99 -0400, Dombrowski, James wrote:
>Eve,
>
>Thanks for the quick response. Your first paragraph mentions "generic
>nesting Section elements that work at any level", but you don't say
>specifically which ones. Can you eleborate? Thanks.

Specifically which section elements or which levels? 🙂 In DocBook,
anywhere that you can have a Sect, e.g. inside Chapter and inside Sect1
through Sect4 themselves, you can have a bare Section element -- literally
....

Eve
Announcements