These comments got my attention, because my group has been planning on using
entities to share information between documents. Can you give some more
specific examples of why this is a bad idea? I understand that parsing
context is an issue, but presume we can work around this by careful
management of our entites and DTD.
To give an example, suppose each of our documents consists of one or more
topic elements, each of which has a heading and one or more paragraphs of
text. If a topic needs to be shared between several documents, it can be
defined as an entity which can then be inserted into multiple documents as
appropriate. Individual paragraphs that need to be shared can be handled in
a similar manner. And so on.
For this to work, writers obviously need to understand the DTD, and to be
aware that specific elements (whether shared entities or no) can only be
used in the context for which they are intended. But that's true no matter
what strategy we use. We will also need a fairly robust system to manage all
this content, and are currently evaluating whether a system like Epic +
Oracle iFS or XMetal + Documentum can meet this requirement. At the very
least, we have confirmed that a tool like Epic has the ability to display
shared entities in context, so that a compound document consisting of
multiple shared entities can be viewed and edited as a single document.
The problem I have with using XSL stylesheets to pull documents together (as
suggested below) is that unless you've got a pretty sophisticated system
that integrates the XSL transformation process into your authoring
environment, it's not clear to me how writers working on different parts can
gain a meaningful view of the whole. And that, it seems to me, places an
even greater burden on the writer than having to keep track of all those
No matter how you slice it, this is complicated (but powerful) stuff...
From: G. Ken Holman [mailto:[log in to unmask]]
Sent: Friday, May 04, 2001 10:21 AM
To: [log in to unmask]
Subject: Re: external entities
At 01/05/04 09:01 -0400, John E. Simpson wrote:
>Janning Vygen wrote:
>>It is so obvious for me its a good idea to split document type definitions
>>across many documents and to allow document type definitions even inside
>>xml data. I cant imagine why this is not part of the w3c rec
Ahhhhhhh ... this is a telling comment and leads me to conclude you were
planning on using external parsed general entities as an information
(anyone remember Eliot Kimber's 8-foot chain-saw metaphor?)
I acknowledge that when people see external parsed general entities, the
intuition is that using these is a good way to share information in many
documents. It is our intuition, but until you get burned by it you will
never realize that the use of external parsed general entities is an
improper information sharing mechanism.
It is a *wonderful* mechanism for splitting a *single* XML document into
many fragments for editing and management, but beyond the surface it is
inappropriate and ultimately incorrect method of sharing common information
between separate instances.
When XInclude finally (PLEASE!!) gets implemented by XML processors, you
will be able to include XML documents wholly into other XML documents (or
even partially when we get ranges in XPointer). Until then one should use
stylesheet technology to merge information from multiple XML documents.
Indeed, since I have numerous XML courses and want to share individual
frames between the courses, one's intuition would think that putting a
single frame into a separate external parsed entity would allow it to be
shared in multiple courses. Instead, I use XSLT and address the frame to
be shared from the remote presentation and selectively add the shared
frames to the output of the course assembly process.
The technical reasons come down the parsing context and that an external
parsed general entity that works fine in one parsing context may fall over
in another parsing context. XML documents only have a single parsing
context as defined by the document's document type definition.
>Yeah, well, there's (IMO) a *lot* of stuff included in/excluded from the
>XML 1.0 Rec which makes little sense to someone coming to XML without
>having first gone through SGML.
But these are tried and true techniques and there is so very much to learn
from the early days.
>(Personally, I thought Ken Holman's outline of how he includes
>(sub)documents very enlightening -- pretty much making possible what you
>want (what *anyone* would want).)
It turns out to be very flexible, though I'll admit my particular
environment may be difficult to pass on to someone else to maintain (and
that's embarrassing; only because new features have been added with no time
to restructure the entire migamarole*).
With the entities I can configure which modules get included in a given
(and in which order), turn on and off features (for example, the
presence/absence of hands-on exercises), redefine the appearance (for
customer branding; some customers want the Crane logo in addition while
others do not), etc. My licensees end up teaching with material that looks
like it is their own.
I hope this helps.
* - "migamarole" - when I grew up this word meant "everything", "the whole
shooting match" ... but I cannot find the word in the dictionary. In *any*
dictionary! Does anyone else recognize the use of this word and help me
with the spelling of it for the next time I want to express this
concept? Is it perhaps just a family concoction that nobody else
uses? Perhaps I just remember another word phonetically incorrect and
can't find a close enough spelling. Answers should be off-list as it isn't
germane to XML.
G. Ken Holman mailto:[log in to unmask]
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/l/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML/OmniMark services, training, products.
Book: Practical Transformation Using XSLT and XPath ISBN 1-894049-06-3
Article: What is XSLT? http://www.xml.com/pub/2000/08/holman/index.html
Next public instructor-led training: 2001-05-14,05-15,05-16,05-17,
Training Blitz: 3-days XSLT/XPath, 2-days XSLFO in Ottawa 2001-06-18/22