Prototype OO was Re: Inheritance/defaulting of attributes

[Liam Quin]

On Thu, 16 Oct 1997, Rick Jelliffe wrote:
> > From: Ken Meltsner <Kenneth.J.Meltsner at jci.com>
>  
> > My point is that it's possible to use an object-oriented approach to
> > manipulate document definitions interactively, and then generate
> > definitions in a form suitable for use by other systems.
> 
> That would be an attractive system.  

It reminds me of a presentation I saw at SGML '89 in Atlanta...
on an "ideal SGML system"... by Pam Genusa or Paula Angerstein I think.

> Usually SGML is used with a version of the "model/view" paradigm,
> where SGML is used to represent the model of the information, nominally
> independent of the systems used to view the information.   So any such
> OO system would be careful to make sure that accurate models can
> be generated that have view information abstracted out as much as 
> possible.

Well, the MVC (Model-View-Controller) paradigm is common not only with
SGML, but on the Macintosh and in OO systems.  It was first described
(as far as I know) in 1980 or 1981 in the Smalltalk books -- there may
have been earlier papers on the subject, though.

SoftQuad's Sculptor SGML product used (uses, if they still sell it) an MVC
paradigm, together with an object-oriented dialect of Scheme. Today one
would probably use Java rather than Scheme because more programmers would
like it, although Scheme goes well with DSSSL.  But once you'd got
over the rather steep learning curve, Sculptor is/was pretty powerful.

I'd say also, take a look at Balise.

SGML lends itself to an object view of the world in a lot of ways,
although you have to be careful not to get too seduced: some aspects,
such as marked sections, enties and comments are from the 1960s sort of
macro text processing, and you end up having to impose all sorts of
restrictions on the SGML you can accept if you're not careful.  One
example is that marked sections, entities and CONCUR can all be used to
make a document that isn't a tree.  RANK and CURRENT and other minimsation
features can be used to make a document where an element's parse depends
on previous elements.. which makes copy and paste exciting too :-)

SoftQuad Sculptor doesn't give much access to the DTD.
Ken, you may want to look at OCLC's FRED research project.
I think this will be particularly interesting when used with
DTD-less XML documents.

Document definitions are much easier to manipulate when represented
as SGML/XML instances (I claim), because then you can use general purpose
tools (like Sculptor, Balise, Omnimark, SGMLS.pm etc).  Then generate
"old-style" DTDs when you need them, along with documentation, and no
more doing things like this:

    <!--*@<B>
	* <desc gi="B">The B element is used to contain the title for
	* a book; use J for journal titles and A for Article titles.
	* Within the B element you can use the general running text elements
	* such as superscript, italic, goldleaf and so forth.<desc>
	*-->
    <!--**<B>: Book title within a citation**-->
    <!Element B
        (%lowLeveltext;)*
    >

This sort of significant-comment stuff is thrown away by most SGML tools --
e.g. it is not represented at all in the ESIS -- and you need to write
specialised software to deal with it (rather like Javadoc or WEB).
Obviously it belongs along with the element declaration, but it's equally
clear that this isn't the best way to do it.  For me, this is the strongest
argument for using an SGML document to store the DTD, even if all you do
is
    <Element name="B">
      <longDesc>
	The B element is used to contain the title for
	a book; use J for journal titles and A for Article titles.
	Within the B element you can use the general running text elements
	such as superscript, italic, goldleaf and so forth.
      </longDesc>
      <shortDesc>Book title within a citation</shortDesc>
      <content>
	(%lowLevelText;)*
      </content>
    </Element>


This is much more amenable to OO tools and methodologies.
If you use an idref instead of the parameter entity:
      <content>
	(<usePE name="lowLevelText"/>)*
      </content>
you can write a DSSSL script to expand it, but you could also imagine
doing automated reasoning based on what "lowLevelText" contains to
produce uses-a/has-a diagrams, for example.

A system written to do this sort of thing could, as you suggest, 
also export information in other formats, such as a database schema for
an OO database, an RTF template (if you add style information, or with DSSSL)
and so forth.

Lee

-- 
Liam Quin --  the barefoot typographer -- Toronto
lq-text: freely available Unix text retrieval

email address: l i a m q u i n, at host: i n t e r l o g  dot  c o m


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)