[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Linking: IDREF vs. HREF

• From: "Michael Kay" <M.H.Kay@e...>
• To: <xml-dev@i...>
• Date: Wed, 3 Dec 1997 11:03:22 -0000

There's been a lot of discussion recently on how to achieve "include"
effects in XML, my problem is how to include "reference" effects.

I am trying to design an XML DTD for encoding genealogical data sets. The
idea is to use the existing data model of the widely-used GEDCOM standard,
but to replace the encoding of the data model with an XML encoding. (Why?
Well I hope
it might be useful to someone and educational for me).

I am wondering how to handle the linking. GEDCOM links are used, for
example, to represent relationships between a person and a family, a person
and another person, or an event and a source. They are relationships in the
data modelling sense, with no hint of presentation semantics. Currently in
GEDCOM you can only have links within a single file: the file contains
records with unique identifiers, very like XML attributes of type ID, and
one record can refer to another using its ID, very like an XML attribute of
type IDREF. So ID/IDREF is the obvious and natural representation of the
current data model.

But I would quite like it to be extensible in the future so a record in one
file can refer to a record in another. This takes one into the domain of the
linking model, where instead of an XML attribute of type IDREF we seem to
need attributes named XML-LINK and HREF. And there are things I can do with
IDREF (like having two IDREF attributes in the same element,
to represent two different relationships) that I can't do with XML-LINKs.

I'm looking for a design that satisfies the immediate requirement, where
references are always to other elements within
the same document, but is naturally extensible to handle references to
elements in a different document (with a "compatible" DTD). Any suggestions
from the experts? Should I, for example, be trying to ensure that the
internal links
work with a parser that doesn't support XLL?

My current and uninformed impression, by the way, is that the whole linkage
model in XLL (and this includes the "embed"
or "include" capability discussed over recent days) has been thoroughly
crippled by a desire to maintain a compatibility with SGML that will give
very little benefit to most of XML's users. My own instinct would have been
to extend the set of attribute types beyond IDREF to include say XREF to say
that the attribute is an XPOINTER with relationship semantics, HREF that it
is an XPOINTER with hyperlink semantics, IREF to say that it is an XPOINTER
with include semantics, etc. If SGML does not allow the set of attribute
types to be extended, that is a serious weakness that should be fixed rather
than circumvented. It's silly to declare the value as being a "string" when
it is actually something much more specific. (I would also like to define
attributes of type boolean, numeric, or date!) Sorry if that opens up old
wounds.

Regards, Mike Kay, ICL
M.H.Kay@e...





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

• Prev by Date: RE: EMBED and validation
• Next by Date: Re: EMBED and validation
• Previous by thread: MIME Notations
• Next by thread: Problems with Entities (was re:Embed and validation)
• Index(es):
  • Date
  • Thread