🚀 go-pugleaf

If we take the InfoMaster Architecture as an application I might
want to implement support for in FrameBuilder, then I have the
following responses to this information.  The InfoMaster Architecture
is a document architecture (analogous to HyTime in approach and scope)
for internal IBM use that defines a set of architectural forms and
base semantics.  The following comments are as one of the definers
of the Architecture and should be taken as an IBM position in any
way.  This is purely my own opinion.

In <9301260142.AA02622@lani.corp.frame.com.frame> Lani Hajagos writes:

>- I mentioned attributes in my previous message. These can be mapped
>into several different FrameBuilder structures, depending on their
>intended usage. There is no concept of current or content reference
>attributes, however.

InfoMaster makes heavy use of content reference attributes (as does
DCF BookMaster and other similar non-SGML declarative markup languages),
both for cross-reference generation and, as an optional feature of
InfoMaster, to enable HyTime content extraction links (conlocx), in
order to re-use the content of an element by reference.  Perhaps
FrameBuilder will support these sorts of mechanisms some other way?

Support for CURRENT does not concern me, but we have defined in
InfoMaster a structure-based inheritance semantic for element
properties (attribute values), that can be modeled using HyTime
default value lists.  Would FrameBuilder provide a way to implement
this semantic?  The InfoMaster Architecture is largely concerned
with managing element properties and hyperlinks, either implicit
or explicit, between elements, to which processing and style can
be applied (e.g., When an element of GI "phrase" has the CLASS= value
"menuitem", present it in small caps AND create an implicit hyperlink
to the definition list item that has a content value that matches
the content of the phrase element and is also has a CLASS= value
of "menuitem" (which may be inherited from its parent)).

Perhaps the better question would be "how much programming work would
I have to do to implement these semantics under FrameBuilder."  A
little? A lot?

>- FrameBuilder has no direct analog to the SGML entity structure.
>FrameBuilder's Book handles documents divided into multiple files,
>although each document in the Book must be a complete element, and
>books cannot be nested.

InfoMaster does not depend on, or expect, any particular text entity
structure, but it does rely heavily on data entities and subdoc
entities.  FrameBuider would have to support preservation of
notation information as well as enable InfoMaster's application-defined
notation property inheritance semantic.  It would have to support,
or enable support of, subdoc entity references (at a minimum, from
ENTITY attributes if not within PCDATA), which InfoMaster uses
chiefly for cross-document hyperlinking.

>- FrameBuilder does not support SGML's optional LINK and CONCUR features.

My feelings on LINK are well known (see recent posts).  Were I
in a position to submit requirements to Frame (e.g., I was buying
the product), I would submit the requirement that FrameBuilder support
implicit and explicit LINK to enable indirect association between
elements and whatever Frame uses to define presentation style and
processing.  I would also like Frame's definition of style and
processing to be as interchangable as possible, but I wouldn't
force the issue (for example, if Frame's composition engine provided
all the composition function I needed for my enterprise's printed
documents AND I could use that composition engine as a batch
formatter across my enterprise, I might not have a need, within my
enterprise, to interchange style information).

>FrameBuilder does have a construct analogous to INCLUDE, IGNORE, and TEMP
>marked sections. This construct, called Conditional Text, however,
>does not support spanning partial elements.
>

While this imposes a constraint not imposed by 8879, I don't think
it's an unreasonable constraint from an InfoMaster Architecture point of
view, since the Architecture constrains all of its semantics to
the markup hierarchy as well.  It might, however, cause difficulty
for someone trying to import a document that relies on "asynchronous"
marked sections to do conditional processing.

Eliot Kimber                      Internet:  drmacro@ralvm13.vnet.ibm.com
Dept E14/B500                     IBMMAIL:   USIB2DK9@IBMMAIL
Network Programs Information Development     Phone: 1-919-543-7091
IBM Corporation
Research Triangle Park, NC 27709