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]
targetNamespace and default namespace

In Eclipse plug-ins we encounter W3C XML Schemas like the following:

<?xml version='1.0' encoding='UTF-8'?>
<!-- Schema file written by PDE -->
<schema targetNamespace="com.google.cloud.tools.eclipse.appengine.libraries"
  <element name="extension">
         <choice minOccurs="1" maxOccurs="unbounded">
            <element ref="library" />
         <attribute name="point" type="string" use="required" />
         <attribute name="id" type="string" />
         <attribute name="name" type="string">
                  <meta.attribute translatable="true" />

Note in particular:

1. elementFormDefault is not specified. Therefore it takes the default
value of unqualified.
2. extension is defined by a top-level element. Therefore the
targetNamespace applies and extension is defined only in the namespace
3. The library element is a child of extension and therefore the
targetNamespace does not apply.

Note the use of a Java package name as a target namespace. That's not
recommended, but what's more shocking are the instance documents this
describes. They look like this:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
id="com.google.cloud.tools.eclipse.appengine.libraries" name="App
Engine Libraries"

Note the complete lack of namespace declarations. In itself this is
not a problem. Documents don't have to use namespaces. However, if I'm
reading the schema spec correctly, this means that this document is
invalid according to the schema. Am I correct? The schema spec is
quite opaque on these matters.

In more generic terms if a schema declares a target namespace, and
elementFormDefault="unqualified", then top-level elements defined in
the schema should be in the targetNamespace. Am I readin this right?

FWIW, I'm primarily concerned with elements here. The extra
complexities of attributes aren't immediately relevant.

Elliotte Rusty Harold

[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