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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] A proposal for application level XML 'namespaces'

In many ways I think the idea of putting all namespace knowledge in 
layer 7 is almost as bad as the current situation where it is split 
between layer 6 (the parser) and layer 7 (the application). Naming is 
fundamental, and the intrastructure should know all there is to know 
about the names of things. Layering namespaces on top of the core XML 
syntax was always a bad mistake and accounts for a good proportion of 
the difficulties we have had with namespaces ever since. For example, it 
should be possible for processing at layer 6 (generic XML processing 
with no knowledge of the vocabulary) to reliably copy fragments of XML, 
and that cannot be done if the meaning is contextual.

I've previously proposed something close to this, but with the rules 
defined at the XML syntax level:

Element names are either absolute (e.g. <:com.example.myschema:parent>) 
or "relative" (<child>) or prefixed (<myschema:uncle>). A relative name 
is expanded using the 'namespace' of its nearest absolute container 
element; if there is none, it is a no-namespace name. The prefix of a 
prefixed name must match the trailing component(s) of a containing 
absolute name, and is expanded to be in the namespace given by that 
absolute name.

Attribute names are the same except that relative names are always 
no-namespace names.

Only absolute names are used in APIs; applications cannot tell whether a 
name was written in full or in abbreviated form.

The namespace :org.w3c.xml and corresponding prefix "xml" are always in 
scope even though there is no containing element in this namespace.

QNames in content should be written as absolute names; if applications 
define their own conventions that are context-sensitive (which we can't 
stop them doing), layer 6 processing will not preserve the context when 
subtrees are copied or transformed.

I feel that this proposal is sufficiently radical to solve most of the 
major namespace hassles, while also having a reasonable mapping onto the 
current situation to allow transition and coexistence.

Michael Kay

On 29/09/2011 18:24, Pete Cordell wrote:
> Dear All,
> Amazing Amy stirred the XML namespaces hornets' nest recently.  I've 
> been thinking about the subject too.  Much of this is based on 
> discussions that have passed before.
> I've come more around to David's (sorry can't remember which one) 
> approach of not using namespaces!  But to accommodate my paranoia 
> about clashes of data, I propose making the document level element be 
> defined as a reverse domain name, (e.g.: com.example.myschema), but 
> then have child elements just have a local name.
> Therefore you would have something like:
> <com.example.myschema>
> <child>12</child>
> </com.example.myschema>
> If you use XML Schema to define your XML you'd do something like:
> <xs:schema xmlns:xs="...">
> <xs:element name="com.example.myschema">
>    ...
> </xs:schema>
> To allow for shorter names the W3C would run an IANA like registry of 
> short name prefixes, such as xml, html, svg, thus allowing document 
> elements with <html.html>, <svg.svg> etc.  All non-registry names 
> would have to have three or more parts.
> References across namespaces would require the full reverse domain.  
> For example, if your XML uses HTML you'd do:
> <com.example.myschema>
> <html.html>...</html.html>
> </com.example.myschema>
> Similarly for attributes.  For example, if it was felt appropriate to 
> bring the XML namespace under this convention (I'm not sure it is), 
> you'd do:
> <com.example.myschema>
> <child xml.id="foo">12</child>
> </com.example.myschema>
> That's about it for element and attribute names.  That leaves QNames.  
> As a general principle I'd make QNames be reverse domain name also, 
> for example:
> <myQName>com.example.value1</myQName>
> To allow for shorter names the XML namespace would have added to it an 
> attribute called xml.prefixes.  An xml.prefixes attribute would 
> declare a set of {short name}/{full name} pairs, for example: 
> xml.prefixes="ex com.example cl com.codalogic".  These mappings would 
> apply to all child elements (and their attributes) of the element it 
> is defined in.
> Then when an application saw a short name in a QName (such as 'ex') it 
> would know to expand it to its full name ('com.example').
> To make it easier for an application, the schema (or similar) would 
> define where an xml.prefixes attribute is allowed to occur.  For 
> example, you'd have to do something like:
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
> <xs:element name="com.example.myschema">
> <xs:complexType>
>         ...
> <xs:attribute ref="xml.prefixes"/>
> </xs:complexType>
> </xs:element>
>  ...
> To enable:
> <com.example.myschema xml.prefixes="ex com.example">
> <myQName>ex.value1</myQName>
> </com.example.myschema>
> Use of xml.prefixes would be a convention that XML vocabulary writers 
> were encouraged to use where appropriate, but wouldn't be required.  
> It has no impact on the XML parser itself.
> Any thoughts?
> Pete Cordell
> Codalogic Ltd
> Interface XML to C++ the easy way using C++ XML
> data binding to convert XSD schemas to C++ classes.
> Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
> for more info
> _______________________________________________________________________
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS