Hi Eric,
Did you intend
to reply to this? I received three identical email messages from you on
July
19, July 20, and July 21, so I’m wondering if there is a glitch in
your email
system.
I’m also cc’ing
the dita-comment list so they don’t miss out on Addam’s message below.
Su-Laine
From:
Addam Smith
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...
Hi Eric,
Thanks
for the reply. I am
wonder if I confused things here a little…I am saying the addition of
the xml
namespace prefix declaration is messing things up. In the DITA
1.1
version of commonElementMod.xsd, the “xmlns:xml” attribute wasn’t
present and
things are okay:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
In DITA
1.2 version, the
“xmlns:xml” attribute is declared on the root xs:schema element and
things no
longer process as I need. If I remove the xmlns:xml attribute, I get
the
processing I need.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xml="http://www.w3.org/XML/1998/namespace">
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Is it
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,….”
The
xs:import for xml namespace
is fine as far as I can tell.
Regards,
Addam
P.S. The catalog-dita-xsd.xml and
catalog-dita-xsd.txt file
from April 2010 zip package have broken entries. Search for “.ent” and
replace with “.xsd” should fix it up.
Hi Su-Laine,
I checked the validation of the schemas with XMLSpy 2007 and oXygen
11.2.
Removing the XML namespace declaration completely from
commonElementsXSD.mod
makes them invalid with Xerces, XMLSpy, LibXML and XSV parsers. If I
remove the circular references to groups in the shell schemas the
schema validates
fine with MSXML .NET in oXygen and Stylus Studio. I was able to
replicate
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 -->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
/> (removed reference to the local xml.xsd file) and it worked
fine.
That said I think that I would still prefer a reference to a local file
so we
can avoid having the XML parser going to W3 to retrieve the actual file.
Excerpts from XML 1.0 Spec (Third Edition).
<snip>
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.
It
MAY, but need not, be declared, and MUST NOT be bound to any other
namespace
name. Other prefixes MUST NOT be bound to this namespace name, and
it MUST
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/.
It
MUST NOT be declared . Other prefixes MUST NOT be bound to this
namespace
name, and it MUST NOT be declared as the default namespace. Element
names MUST
NOT have the prefix xmlns.
All other prefixes beginning with the three-letter sequence x, m, l, in
any
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
prefixed
names whose LocalPart begins with the letters x, m, l, in any case
combination,
as these names would be reserved if used without a prefix.
</snip>
<snip>
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
where
the prefix is used or in an ancestor element (i.e., an element in whose
content
the prefixed markup occurs).
</snip>
Xerces, XMLSpy, MSXML 6.0 (Sax and DOM via Stylus Studio), LibXML and
XSV all
validate a test DITA file properly.
MSXML .NET has an issue (known) with circular references in the XSDs -
This is
an issue with the parser since it's perfectly valid as per the XSD 1.0
spec.
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
without
a reference to the namespace in commonElementMod.xsd.
According to the MSXML 4.0 SP3 Release notes [1] 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
DITA 1.0)
for a version of a product that's in maintenance mode and that the
issue is resolved
in newer versions of the product.
Kind regards,
Eric
[1] - 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:
I’m
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
will
load commonElementMod.xsd or documents referencing this schema.
Instead,
a parse error is reported to the effect that “The namespace prefix is
not allowed
to start with the reserved string "xml". At line(24),
column(56).”
Microsoft’s interpretation of Namespace
constraint:
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
anytime
soon, I recommend removing the xml namespace
declaration
in commonElementMod.xsd schema so DITA 1.2 content can be parsed by MS
technologies.
Regards,
Addam Smith
JustSystems
-----------------------------
Su-Laine Yeo
Solutions Consultant
JustSystems Canada, Inc.
Office: 778-327-6356
syeo@justsystems.com
www.justsystems.com
XMetaL
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