Lists Home |
Date Index |
That's the solution I've used and has been used since
time immemorial in yeOldeDocumentDatabases. Locally,
we call it a joins table. I once implemented a
treeview object for such and it was the one time
that namespace URIs really came in handy. When we
have to create ERDs and document tables, pulling all
of the relationships into a simple meta-table is
useful and avoids sparseness.
The external pointers approach comes in handy when
one has multiple endpoints in files/entities/things
of different formats. That is why Hytime originally
required notation declarations and there was a concept
of link types. The local anchor identifies the
link which identifies the notation which identifies
the target type handler. So the function/dll is named
and is passed the link type and the identifier for
the target. The target might be read-only and might
not be markup and might not have locally stored
names for location purposes. So Hytime had types
such as nameloc (where a name can be used), treeloc
(what got into XPointer and XPath), and so on. One
could use byte offsets for links, and so on. There
is set of constructs for using dimensions so it was
easy to do what HTML later did with maps.
Most use namelocs and treelocs and the dimensional
locators that I've encountered.
From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
Hmm, we set out to implement a tree management database and ended up
building some limited forms of graphs out of it. You end up cross
referencing the nodes in the trees via another table. Sounds like the
same thing attacked backwards.
> can easily represent very complex sets of relationships - something
> trees will never do. to me this means xml must struggle as
> or document complexity increases,
I've been trying to say exactly this throughout this thread, thank you
for the succinct way of putting it.
> so there will be a
> requirement for a
> meta-xml (MXML?).
I'm still wondering if something like Gavin's external pointers on top
of XML wouldn't suffice?