OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Inheritance and other buzzwords

[ Lists Home | Date Index | Thread Index ]
  • From: "W. Eliot Kimber" <eliot@isogen.com>
  • To: xml-dev@ic.ac.uk
  • Date: Thu, 02 Apr 1998 17:57:20 -0600

At 03:20 PM 4/2/98 -0800, Tim Bray wrote:

>I do not understand architectural forms well enough to have an opinion
>as to how well they co-exist with universal names.  But Eliot doesn't
>seem too worried by it.

They are orthoganal.  Architectures define instance-to-type mappings. Name
spaces ensure that instance or type names are universally unique.

For example, say I want to define a generally-usable set of elements. In
SGML architecture terms, I would define them by creating an architectural
DTD that declared the element types and attributes:

<!-- File kimarch.dtd -->
<!-- Declarations for KimArch -->
  uname="urn:fpi:+//IDN drmacro.com//NOTATION Kimber Architecture//EN"
<!ELEMENT kimarch:kimdoc
<!ELEMENT kimarch:para
<!-- End of declarations -->
<!-- End of file -->

Note my use of name spaces to ensure that these element type names are
unique. This has no value to these declarations as an architectural DTD
(because it the element types are inherently unique because an architecture
establishes its own element type name space). But it might be useful if
people want to syntactically combine these declarations with others in
individual documents or in other architectural DTDs, which is not something
architectures explicitly enable (or even encourage) but that is possible
because architecture DTDs use normal DTD syntax.

Within a document, I can either use the colonized names or not. If I use
the colonized names, then an architecture-aware processor will map the
instance names to the architectural names automatically, making the
instance indistinquishable from a name-spacified document except by the
presense of an architecture use declaration:

<?xml version="1.0"?>
  uname="urn:fpi:+//IDN drmacro.com//NOTATION Kimber Architecture//EN"
<?IS10744 arch name="kimarch" system-id="kimarch.dtd"?>
<kimarch:para>This is a kimber-defined paragraph</kimarch:para>

Here I've enabled name-space aware processing (whatever that means) and
architecture-based processing. Both appear to use the same syntactic
mechanism, but in fact the architecture-based processing is just plain
string matching--there's no awareness of "kimarch:" as being a prefix.  In
other words, architecture processing doesn't care how the element type
names (or attribute names) are spelled.  Of course, we could enhance
architectural automapping to recognize prefixes, which is probably a useful
thing to do.

To use my own element type names, I use the attribute-based remapping
mechanism instead of colonized names, which is exactly the same as that
defined by XLink:

<?xml version="1.0"?>
<?IS10744 arch name="kimarch" system-id="kimarch-noprefix.dtd"?>
<mydoc kimarch="kimdoc">
<stuff kimarch="para">This is a kimber-defined paragraph</kimarch:para>

The only change here is that I provide a non-colonized version of the
architectural DTD (I could have used the colonized version but it would
look really stupid to repeat "kimarch" for each mapping):

<!-- File kimarch-noprefix.dtd -->
<!-- Declarations for KimArch -->
<!ELEMENT kimdoc
<!ELEMENT para
<!-- End of declarations -->
<!-- End of file -->

The architectural mapping is the same. Note that as shown here the
syntactic result is only slightly different from the name-space version
('kimarch="name"' instead of 'kimarch:name', a difference of two
characters).  Of course, it doesn't, by itself, serve to make the element
type name universally unique. But since I see no value in doing so, I don't
care. If I did care, I'd use name spaces.

Finally, I have a document somewhere that defines what the element types in
the  kimarch architecture mean:

<?xml version="1.0"?>
<title>The Kimber Architecture</title>
<p>The architecture name "kimarch" can be used as a name-space
prefix in name-spacified versions of the kimarch architectural
DTD if desired.
<p>A document</p>
<p>A paragraph.</p>

The existence of an architecture definition document completes the
definition of the architecture (at least in a trivial, if uninteresting,
way). This definition document could be the same one used to describe the
names in the name space, don't know. In any case, it serves to define a set
of element types and their meanings, which is what I think a schema is.


<Address HyTime=bibloc>
W. Eliot Kimber, Senior Consulting SGML Engineer
Highland Consulting, a division of ISOGEN International Corp.
2200 N. Lamar St., Suite 230, Dallas, TX 95202.  214.953.0004

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS