SAX and delayed entity loading

[W. Eliot Kimber]

At 06:57 PM 12/3/98 -0500, Chris Maden wrote:

>MIME types or notations eventually come down to a magic word of some
>sort.  MIME types work now; notations don't yet.
>
>I want a notation to make it *go*, not tell me what to read to make
>something to make it go.  Since we're not all using the same
>programming language, magic cookies are the only workable solution;
>MIME combines this with robust, well-defined fallback behavior.

Let's try this code from my PHyLIS tool, which associates grove constructor
objects (COM objects in this case, because I'm implementing on Windows),
with the external IDs for the notations those grove constructors support.
A grove constructor is a software component that takes an entity (or
another grove or subgrove) as input and constructs a grove from it. Grove
constructors are associated with the notations they understand. PHyLIS, as
a generalized tool, lets you create and plug in grove constructors for any
data content notation.  An entry from the configuration file for PHyLIS
looks like this:

<grovecon>                                   <!-- Configure a single grove
constructor -->
<COM-progid>PHyLISlib.SPSGMLGC</COM-progid>  <!-- Implementing software
component -->
<notation-extid>sgml</notation-extid>        <!-- External IDs of notations
this GC understands -->
<notation-extid>SGML</notation-extid>
<notation-extid>ISO 8879:1986//NOTATION Standard Generalized Markup
Language//EN</notation-extid>
</grovecon>

The code below reads the configuration and sets up a table that maps the
notation external IDs to the grove constructor software object.  This is,
as far as I can tell, just what you do with MIME types. I could, in fact, I
suppose, support the association of grove constructors with MIME types as
well (I get that for free if they are used as notation external IDs).  Note
that this dependence on notations (and, by implication, entity
declarations) doesn't preclude doing MIME-only based association of
resources addressed by means other than entity with grove constructors, but
that's not how the HyTime standard is currently defined (nor, I think,
should it be).  When I create an XLink-only version of PHyLIS, of course
I'll have to do that (because it will still be grove based, of course).

' At this point, we've parsed the configuration doc and found a grovecon
element. This
' bit is in a loop that iterates over the grovecon elements.

    Set gcelem = PHyLISlib.child_of_type(workelem, "grovecon")
    ' gcelem is grovecon element
    Do While Not gcelem Is Nothing
        Set workelem = PHyLISlib.element_child(gcelem, 1)
        ' workelem should be COM-progid elem
        If Not workelem Is Nothing Then
            With mobjGroveManager
              If workelem.Gi = "COM-progid" Then
                progid = PHyLISlib.Data(workelem)
                Set workgc = mobjGroveManager.CreateGroveCon(progid) '
Instantiate the object
                If Err.Number <> 0 Then
                    MsgBox "Error: Unable to create grove constructor object."
                Else
                    ' At this point, workelem is COM-progid
                    Set workelem = PHyLISlib.next_element_sibling(workelem)
                    Do While Not workelem Is Nothing
                      If workelem.Gi = "notation-extid" Then
                        extid = PHyLISlib.Data(workelem)
                        '------------------
                        ' !!! HERE IT IS:
                        '------------------
                        mobjGroveManager.RegisterGroveCon workgc, extid
                        ' This function adds an entry to table that lets
you look up the 
                        ' grove constructor by notation external ID.
                      End If
                      Set workelem = PHyLISlib.next_element_sibling(workelem)
                    Loop
                End If
              End If
            End With
        End If
        Set gcelem = PHyLISlib.next_element_sibling(gcelem)
    Loop

This is a system that provides completely generalized support for
associating notations with notation-specific processors.  The same
technique is used to bind processors for other types of notations (query
notations, storage manager notations, property sets, viewable object
notations, etc.).   I haven't implemented support for superclass notations
(for fallback), but I plan to.

My plan is to have PHyLIS prompt for user intervention when it encounters a
notation for which it doesn't have an available component.  You should be
able to find and download a grove structor (should one exist) or renderer
for a particular property set, plug in, add it to the mapping table, and
off you go.  This is no different from following a link to a resource for
which you have no renderer or plug-in available (or correctly registered on
your machine) and having to figure out what to do about it (I was always
having this problem with VRML--now I have the opposite problem, IE5B2
thinks all .gz files are VRML worlds--I had to disabuse it of that notion
right away, unfortunately, it took a rather heavy blow to do it).

I ship PHyLIS with a default configuration, of course, just as your Web
browser comes with a default set of MIME-to-object mappings.  If all you
need is what PHyLIS provides out of the box, you'll never have to worry
about it, just as with Web browsers.  But if someone gives you a document
with a unqiue notation, they better also provide you with the necessary
constructors and renderers, or it's just a text file--but that's always the
case. The use or non-use of notations or MIME types can't change that.  

All that notations or MIME types are about is providing a way that
reasonably persistent names for things can have some reasonably intelligble
mapping to a definition of what they are so that tools like PHyLIS and Web
browsers and the users of those tools have some hope of configuring things
correctly.  But they aren't magic--they don't remove the need for humans,
usually users of individual computers, to keep their systems configured
appropriately and they can't eliminate the problem of getting data that
your system doesn't yet know how to deal with it.

That's why, in the end, it always comes back to documentation for
humans--at some point some human has to know that "foo" means "this kind of
data" and has to know that on their system at that point in time, software
component X is the appropriate tool to use on that data.  Nothing about
MIME or notations can change this.

Cheers,

E.
--
<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 75202.  214.953.0004
www.isogen.com
</Address>

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)