Lists Home |
Date Index |
- From: james anderson <James.Anderson@mecomnet.de>
- To: "email@example.com" <firstname.lastname@example.org>
- Date: Wed, 01 Jul 1998 12:21:21 +0200
what is the advantage to leaving the articulation (URI x local) part open in
this interface? why isn't the parameter an opaque object? i'm not sure what
the application concern is, but, for the relations which occurred to me, there
are better ways to do that than having to broaden all name-related interfaces.
if the issue is to "identify" symbols which, by prefix, reside in different
regions of the articulated namespace, it could be done on a prefix to prefix
basis or on a region to region basis - depending on whether the specification
has a dynamic or an indefinite extent.
if the issue is that one wants to do that on a name-by-name basis, there are
better ways for that too. one could use a combination of importing and
exporting names among regions.
if the issue is that one whats to articulate the mapping per element, there
are other ways to do that too, though i'm unclear why one would.
MURATA Makoto wrote:
> [re remarks from Peter Murray-Rust re attribute inheritance]
> Of course, this has to become namespace-aware. That is, the argument
> of setInheritedAttribute should be a pair of URI and local part.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)