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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: why do namespaces have such a bad rep [3]

[ Lists Home | Date Index | Thread Index ]
  • From: "Steven R. Newcomb" <srn@techno.com>
  • To: James.Anderson@mecom.mixx.de
  • Date: Fri, 3 Apr 1998 12:42:38 -0500

[James Anderson <James.Anderson@mecom.mixx.de>:]

> i'm concerned about the case were i want to get at [the base
> architecture's parameter entities], not be isolated from them.  i
> would expect to have to do something like the following. suppose
> that i have two base architectures, each with an element "name". i
> would like to derive an architecture to comprise descriptions of
> both sorts. nothing new.

> <!-- base arch 1. -->
> <!ELEMENT name ((first, last) | %name-content;) >
> <!ATTLIST name
>   address-form (PSEUDONYM | LEGAL) "LEGAL">
> <!-- base arch 2. -->
> <!ELEMENT name %name-content; >
> <!ATTLIST name
>   address-form (ASSOCIATIVE | LITERAL) "LITERAL">

> while the provisions of enabling architectures make it possible to
> use architectural form attributes to disambiguate the "name" element
> names by creating a 2-d namespace for element names, and to
> disambiguate the "address-form" attribute names by using the
> remapper attribute to, likewise, create a 2-d namespace for
> attribute names, and then to map them onto unique positions within a
> 1-d namespace, i have not found the provision to enable declaring
> distinct values for the entities. how would one distinguish
> %name-content from %name-content in a derived architecture in order
> to specify the respective entity declarations?

> maybe i don't need to. i thought i would.

I don't think you need to.  When you create an element subtype from an
element type in a base architecture (a supertype), it doesn't matter
whether the content model of the supertype was expressed by means of
one or more parameter entities.  For all purposes of subtyping, it
only matters what the replacement text of those parameter entities
was.  I can see where it might sometimes be convenient to re-use the
same parameter entities that were used in the base architecture, but
there is no provision in the current enabling architectures syntax for
that, and it's not necessary, anyway.  I doubt it would be worth the
added syntactic complexity.  You would have to cause the names in the
replacement texts of the supertype's architecture's parameter entities
to be somehow automagically translated into the corresponding names in
the subtyping architecture.

[I'm trying to use the "subtype/supertype" vocabulary instead of the
"inheriting/inherited" vocabulary here; does it work better?]


Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 231 4098 (at ISOGEN: +1 214 953 0004 x137)
fax    +1 972 994 0087 (at ISOGEN: +1 214 953 3152)

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

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