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

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

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>
>