HyperXanaCardDu

[Rick Mascitti <acad!blitzen!rick>]

marcs,

I'm not gonna give this one up, 'cause there's either something I
don't understand, or I'm butting my head up against the wall of
science.  It seems that you folks, for some reason I cannot fathom,
want to define all the document types in the world so you can store
and link them.  If that's the case, I scream "No, No, a thousand
times No!"  Provide the best, simplest abstractions and let me,
the application developer, put them together in useful ways.

Using HyperCardus Clonus as an example, I still don't see how 2
abstractions don't suffice:  textual data and inclusion lists.
I elaborate (please forgive the cheesy ASCII graphics):


Stack doc

    Inclusion list -+--   \
                    |     |
                    +--   |
                    |     +- links to "Card class" docs
                    +--   |
                    :     |
                    :     /

                    link typenames describe card ranges (e.g. "1-20")

    Card range<->ID mapping table

Card class doc

    Inclusion list -+-- link to background graphic
    (Description)   |
                    +-- link to background field&button doc

                    link typenames "graphic", "bg f&b"


    Inclusion list -+--   \
                    |     |
                    +--   |
                    |     +- links to Card field&button docs
                    +--   |
                    :     |
                    :     /

                    link typenames are card numbers


field&button doc

    Inclusion list -+--   \
                    |     |
                    +--   |
                    |     +- links to ordered field/button docs
                    +--   |     (mixed, back-to-front)
                    :     |
                    :     /

                    link typenames are "field ID/num", "button ID/num"

field docs
button docs
    description of appropriate "properties"
    link to appropriate "contents"
        (for fields -- the info contents
         for both -- the HyperTalk scripts)



Application retrieval algorithm:
+-->Get stack doc (cache it)
| +>Get card class doc (cache it)            -- links from stack doc
| | Display background graphic               -- link from card class*
| | Get background field&button doc          -- link from card class*
| | Display background fields & buttons      -- links from card class*
| | Get card instance doc (field&button doc) -- link from card class*
| | Display card fields & buttons            -- links from f&b doc
| |
| | On "go to card"-+
| +-----------------+
|   On "go to stack"-+
+--------------------+

                           *might want to package requests for speed

What does this picture assume?  1) I can tag linknames arbitrarily.
2) I can store and retrieve a graphic (even if as an opaque "Packet
O'Bits").  3) "Go to X" places a link to the appropriate X.  (might
need some kind of Stack mapping table.)

What's wrong with this picture????  And as for "properties" and
property list representations, I'll save that one for another
discussion.

rick