Re: Namespaces? (was: Enlightenment via avoiding the T-word)

[Seairth Jacobs <seairth@seairth.com>]

I understand exactly what you are saying here.  I guess my mistake in the
original posting was that I was trying to suggest an alternative to the
Namespacing by making this a schema definition issue and not a schema
resolution issue.  By defining a superset schema that encompassed and
resolved the conflicts in several sub-schemas, there is no longer the need
to resolved the conflicts at the document instance level.

Further, in an earlier post, Tim Bray made the following comment:

    "... [I] suggested a few emails back that if you want to ensure that you
only have to do heavyweight schema  lookup once, you decorate each node with
a pointer to the applicable schema rule."

In effect, this technique would be able to do exactly what Tim suggests.
Okay, I hear all of the head-scratching right now, but bear with me...
Suppose the following premise:

When one wants to take two schemas and use some or all of each of them, they
define a new schema that encompasses them.  The new schema takes on the
appearance of both schemas combined.  Where there is conflict between the
schemas, the new schema resolves the conflict by renaming one or more of the
conflicting elements.  Further, even if there isn't an actual conflict (at
least in terms of two identically named elements that can have the same
XPath), it would still be possible to rename any element you wanted.  This
would allow you to take two non-conflicting elements with the same name
("globally" scoped"), and rename one if desired.  For that matter, you may
choose that the <name> element of one of the source schemas isn't
appropriately descriptive of your usage and so choose to rename it as
<fullname>.  Under this concept, you could even insure that each and every
element was uniquely named within your schema at the "global" level.  And
all of this is done without changing one single thing about the underlying
schemas.

Now, the next question would be how we would process this...  Suppose that
you had a validating parser that "understood" several defined schemas.  For
the sake of this example, suppose we need use of two well-defined schemas:
Schema1 and Schema2.  First, you create a new schema (MySchema) definition
that will be nothing more than a wrapper for those two schemas.  As it turns
out, both have a <name> element defined which can have a conflicting XPath.
As a result, the <name> in Schema2 is renamed in MySchema to <fullname> (or
it could be <Schema2:name> if you wanted to use a namespace-like format).
Now, as the parser is loading the MySchema definitions, it sees the
references to the underlying schemas, which it also loads.  Then, it sets up
an "alias table" that would include an entry for Schema2's <name> element
named <fullname>.  Now, when the parser encounters a <fullname> element in a
document instance, it has a quick way of looking up the actual associated
element definition.  In a way, this is as Tim said: "decorate each node with
a pointer to the applicable schema rule".  I realize that the particular
method outlined above may not be the most optimized method, but I can think
of at least two other similar techniques that would have the same effect.

Now, what does all of this mean?  Well, to me it means that there is no need
for Namespaces in it's current form.  Since all documents conform to a
single schema only, there is no need to resolve name conflicts at the
document instance level.  The aliasing/renaming of the conflicting names is
left up to the implementer of the new schema.  As this only effects the
implementer and those that choose to use the new schema, this allows
everyone else to use the same underlying schemas in their own way as
necessary.  In the end, people who are sharing schemas only need to be
concerned with their own domain.  Others who are borrowing from multiple
domains are creating a domain of their own with concerns of their own.  It
seems reasonable to me that each domain should be allowed to use it's own
schema definitions that borrow to whatever extent it chooses from other
domains without being restricted to the actual names of the elements being
used in the borrowed schema(s).


Seairth Jacobs
seairth@seairth.com


----- Original Message -----
From: "Fuchs, Matthew" <matthew.fuchs@commerceone.com>
To: "Seairth Jacobs" <seairth@seairth.com>; "xml-dev"
<xml-dev@lists.xml.org>
Sent: Thursday, August 30, 2001 12:56 PM
Subject: RE: Namespaces? (was: Enlightenment via avoiding the T-word)


> The point about Namespaces that I think you're missing is that the
different
> schemas (or Schemas) referenced from within an instance are never
explicitly
> combined - no one sits down and alpha renames away all clashes and then
> rewrites the instance which put the together, and makes sure that all the
> software you have based on the names in the precombined schemas is
rewritten
> to use the new names.  Namespaces allows all the disambiguation to occur
in
> the instance without touching the schema
>
> Matthew
>
> > -----Original Message-----
> > From: Seairth Jacobs [mailto:seairth@seairth.com]
> > Sent: Wednesday, August 29, 2001 7:26 AM
> > To: xml-dev
> > Subject: Namespaces? (was: Enlightenment via avoiding the T-word)
> >
> >
> > It seems to me that the whole Namespace concept (as it is
> > currently defined)
> > is ill-fated in the end.  In truth, a Namespace implies the
> > existence of a
> > schema, whether the schema is defined with XML Schema or is
> > only in one's
> > head.  If you have a single XML document and that document
> > conforms to a
> > single schema, then no Namespace is necessary.  Where
> > Namespaces come in is
> > when you want to mix more than one schema together (e.g. your
> > own schema +
> > XML Datatypes).  On top of that, it is only necessary when there is an
> > element or attribute name that is identical within more than
> > one underlying
> > schema.
> >
> > The problem with the XML Namespace specification is that it
> > is designed to
> > disambiguate the two schemas at the document instance level.
> > However, by
> > the very fact that you have taken two or more schemas and put
> > them together,
> > you have effectively defined a new superset that is a single
> > schema itself.
> > As a result, I would think it more appropriate to resolve
> > Namespace conflict
> > within the schema definition itself instead of in the
> > document instance.
> >
> > When you have two schemas that both have a <name> element,
> > then you would
> > disambiguate them in whatever way was appropriate.  This would only be
> > necessary when the same element name from each schema can be
> > used within the
> > same XPath.  In this case, one of the elements could be
> > renamed to something
> > like <myschema:name> or <address_name>.  Whatever name is
> > chosen doesn't
> > matter because the renaming is occurring within the definition of the
> > superset schema.  Once a matching document is processed,
> > there is no issue
> > at all concerning the new name.  From a processing view, I
> > would think this
> > to be less computationally intensive, since the conflicts
> > would be resolved
> > once with the initial schema definition instead of for each document
> > instance.
> >
> >
> > Now, there are two main counterarguments that people have
> > already expressed
> > here:
> >
> > 1) Whether an element is of global or local scope.
> >
> > Let's face it, the XML specification clarifies this already.
> > All elements
> > are of local scope.  The XML specification itself does not
> > give any way to
> > access a given element name globally.  Further, suppose that you had a
> > <name> element inside of an <address> element.  If you were
> > to remove the
> > <address> element, the <name> element would go too (since it
> > is inside the
> > <address> element).  The <name> element only exists within
> > the scope of the
> > <address> element.  The <name> element is not global.
> >
> > Further, I do not know of any application that would perform
> > a sweeping
> > change to all <address> elements found within a document without first
> > knowing the context of the <address> element.  This could be
> > as simple as
> > making the implicit assumption that the document conforms to
> > a schema that
> > has only one definition of <address> (and therefore can
> > safely "ignore" its
> > scope).  This could be a complex as performing various levels
> > of validation
> > to filter out only the significant <address> elements (which
> > would require
> > explicit knowledge of its scope).  In either event, the definition is
> > "known".
> >
> >
> > 2) Whether an element should be renamed from <name> to
> > <shipping_address_name> in the source schema.
> >
> > The SQL examples gave a good example of this issue.  When you have two
> > tables, each of them are defined according to their own
> > schema.  When you
> > select fields from both of them, you get a new table with its
> > own schema
> > definition. When there is a name conflict, you resolve it be
> > renaming at
> > least one of the conflicting fields to a unique name.  This
> > is done at the
> > schema definition level.  There is no necessity to continue
> > resolving the
> > name conflict while accessing the new table because it has
> > already been
> > done.
> >
> > Does this mean that we should rename the source table field
> > names to be
> > unique?  Of course not.  Within each table schema definition,
> > the names make
> > sense and are unique.  It is only when we choose to mix the
> > two schemas that
> > we need the resolution.
> >
> >
> >
> > So, in the end:  Scrap XML Namespaces.  Resolve name
> > collisions within the
> > schema definition process itself. The end.
> >
> >
> > ---
> > Seairth Jacobs
> > seairth@seairth.com
> >
> >
> >
> >
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> >
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> >
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
> >
>
>