Did you intend
to reply to this? I received three identical email messages from you on
19, July 20, and July 21, so I’m wondering if there is a glitch in
I’m also cc’ing
the dita-comment list so they don’t miss out on Addam’s message below.
Sent: Tuesday, July 20, 2010 6:31 PM
To: Eric Sirois; Su-Laine Yeo
Subject: RE: [dita-comment] FW: Declaration of "xml" namespace
in commonElementMod.xsd incompatible with Microsoft XML technologies...
for the reply. I am
wonder if I confused things here a little…I am saying the addition of
namespace prefix declaration is messing things up. In the DITA
version of commonElementMod.xsd, the “xmlns:xml” attribute wasn’t
things are okay:
1.2 version, the
“xmlns:xml” attribute is declared on the root xs:schema element and
longer process as I need. If I remove the xmlns:xml attribute, I get
processing I need.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xml="http://www.w3.org/XML/1998/namespace">
possible for Xerces,
LibXML et al to work without the redeclaration of the “xml” namespace
prefix. As per namespace prefix restrictions, “It MAY, but need not, be declared,….”
xs:import for xml namespace
is fine as far as I can tell.
P.S. The catalog-dita-xsd.xml and
from April 2010 zip package have broken entries. Search for “.ent” and
replace with “.xsd” should fix it up.
I checked the validation of the schemas with XMLSpy 2007 and oXygen
Removing the XML namespace declaration completely from
makes them invalid with Xerces, XMLSpy, LibXML and XSV parsers. If I
remove the circular references to groups in the shell schemas the
fine with MSXML .NET in oXygen and Stylus Studio. I was able to
the issue with MSXML 4.0 from oXygen. If I use MSXML 6.0 to validate a
document from Stylus Studio, it validates fine with DOM or SAX.
I made the following change in commonElementsMod.xsd -->
/> (removed reference to the local xml.xsd file) and it worked
That said I think that I would still prefer a reference to a local file
can avoid having the XML parser going to W3 to retrieve the actual file.
Excerpts from XML 1.0 Spec (Third Edition).
Namespace constraint: Reserved Prefixes and Namespace Names
The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace.
MAY, but need not, be declared, and MUST NOT be bound to any other
name. Other prefixes MUST NOT be bound to this namespace name, and
NOT be declared as the default namespace.
The prefix xmlns is used only to declare namespace bindings and is by
definition bound to the namespace name http://www.w3.org/2000/xmlns/.
MUST NOT be declared . Other prefixes MUST NOT be bound to this
name, and it MUST NOT be declared as the default namespace. Element
NOT have the prefix xmlns.
All other prefixes beginning with the three-letter sequence x, m, l, in
case combination, are reserved. This means that:
* users SHOULD NOT use them
except as defined by later specifications
* processors MUST NOT treat
them as fatal errors.
Though they are not themselves reserved, it is inadvisable to use
names whose LocalPart begins with the letters x, m, l, in any case
as these names would be reserved if used without a prefix.
Namespace constraint: Prefix Declared
The namespace prefix, unless it is xml or xmlns, MUST have been
declared in a
namespace declaration attribute in either the start-tag of the element
the prefix is used or in an ancestor element (i.e., an element in whose
the prefixed markup occurs).
Xerces, XMLSpy, MSXML 6.0 (Sax and DOM via Stylus Studio), LibXML and
validate a test DITA file properly.
MSXML .NET has an issue (known) with circular references in the XSDs -
an issue with the parser since it's perfectly valid as per the XSD 1.0
Once those are removed the test DITA file validates properly.
MXSML 4.0 complains about XML namespace.
MSXML 6.0 seems to be only product that can validate the test DITA doc
a reference to the namespace in commonElementMod.xsd.
According to the MSXML 4.0 SP3 Release notes  support for MSXML 4.0
SP2 ended in mid April 2010 and SP3 is in maintenance mode. I'm a bit
hesitant to make a change to the schemas (that has been there since
for a version of a product that's in maintenance mode and that the
issue is resolved
in newer versions of the product.
 - http://download.microsoft.com/download/A/2/D/A2D8587D-0027-4217-9DAD-38AFDB0A177E/MSXML4%20SP3%20RTM%20Release%20Note.htm
On 7/19/2010 6:34 PM, Su-Laine Yeo wrote:
passing this along on behalf
of a colleague:
In the DITA 1.2 XSDs, commonElementMod.xsd
was changed to
declare the "xml" namespace. This change causes problems when
using Microsoft XML processor technologies. Neither MSXML nor .NET
load commonElementMod.xsd or documents referencing this schema.
a parse error is reported to the effect that “The namespace prefix is
to start with the reserved string "xml". At line(24),
Microsoft’s interpretation of Namespace
Reserved Prefixes and Namespace Names ends up that
“nobody” can explicitly declare the “xml” namespace. Given the MS
technology has been this way a long time and thus unlikely to change
soon, I recommend removing the xml namespace
in commonElementMod.xsd schema so DITA 1.2 content can be parsed by MS
JustSystems Canada, Inc.
Community Forums: http://forums.xmetal.com/
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.839 / Virus Database: 271.1.1/3016 - Release Date: 07/19/10 14:36:00