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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: XSchema Spec, Section 3, Draft 1 (Namespaces)

[ Lists Home | Date Index | Thread Index ]
  • From: james anderson <James.Anderson@mecomnet.de>
  • To: "xml-dev@ic.ac.uk" <xml-dev@ic.ac.uk>
  • Date: Wed, 01 Jul 1998 12:23:06 +0200

if the namespace pi becomes the standard way to express the binding between a
prefix and a namespace region, then parsers will need to support it. if it
doesn't then some other mechanism will become standard.

i really don't care what the mechanism is. (seven months ago my associations
with neither "element" nor "pi" were pleasant, as they were still dominated by
a certain "ms.godsee" and "mr.goldstein", nether of whom were particularly inspiring...)

what matters is that, once one is standard, the mechamisms to provide for
symbol distinction / identity will already exist. it doesn't make sense to
require that a second mechanism duplicate (part of) the behaviour of the
first. any processor which can read a document which follows the scahem spec
will already have to be "namespace aware". it makes much more sense to require
of the first mechanism, that it offer an (additional) interface function of
the form
  (document X qualified-name ) -> symbol.
yes, this is missing in the present namespace proposal. which is reason to fix
it (given that it's still in flux), not reason to do something else.

for documentary purposes, or to bind a schema to the ns identifier if/once the
src attribute gets dropped from the namespace pi, a namespace declaration for
xschema makes perfect sense.

Simon St.Laurent wrote:
> 
> James Anderson wrote:
> >the extra resolution mechanism, should it be necessary, still does not
> >require an additional means of expression.
> 
> I'm still in the b) camp.  I really don't want XSchemas to have to rely on
> _any_ PIs; I'm even irritated by the PI needed for the XSchema namespace
> itself.  PIs are gradually blooming across the XML landscape like hideous
> rotten flowers.  (Yes, I'm strongly biased against PIs, if you hadn't noticed
> already.)

an encoding which requires that information appear redundantly makes sense
only in the face of noise or some other potential for misinterpretation.
that's not the problem here.

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