can't parse W3 SOAP 2003-05 envelope XML schema: "xml:lang" attr ref

[Tomas-Kraus]

I was trying to use JAXB to parse the MMAP schema from the SMS Forum
(http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd). I finally
tracked it down to XJC choking on the included SOAP envelope schema's
use of the xml:lang attribute for a tag called reasontext. Here's the
pared-down test case:

C:\java\src\baz>%JWSDP_HOME%\jaxb\bin\xjc.bat http://www.w3.org/2003/05/soap-
envelope/soap-envelope.xsd
%JWSDP_HOME%\jaxb\bin\xjc.bat http://www.w3.org/2003/05/soap-envelope/soap-
envelope.xsd
parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'xml:lang' to a attribute
declaration component.
line 97 of soap-envelope.xsd

[ERROR] src-ct.0.1: Complex Type Definition Representation Error for
type 'reasontext'. Element 'attribute' is invalid, misplaced, or occurs too
often.
line 97 of soap-envelope.xsd

Failed to parse a schema.
C:\java\src\baz>

I believe that the relevant portions of the schemas and namespaces in
question are:

http://www.w3.org/2003/05/soap-envelope/soap-envelope.xsd

<xs:complexType name="reasontext">
xs:simpleContent
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>

http://www.w3.org/2001/XMLSchema.xsd

<xs:complexType name="attribute" mixed="false">
xs:complexContent
<xs:extension base="xs:annotated">
xs:sequence
<xs:element name="simpleType" minOccurs="0" type="xs:localSimpleType" />
</xs:sequence>
<xs:attributeGroup ref="xs:defRef" />
<xs:attribute name="type" type="xs:QName" />
<xs:attribute name="use" use="optional" default="optional">
xs:simpleType
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="prohibited" />
<xs:enumeration value="optional" />
<xs:enumeration value="required" />
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="default" type="xs:string" />
<xs:attribute name="fixed" type="xs:string" />
<xs:attribute name="form" type="xs:formChoice" />
</xs:extension>
</xs:complexContent>
</xs:complexType>

http://www.w3.org/2001/XMLSchema.xsd

<xs:attributeGroup name="defRef">
xs:annotation
xs:documentationfor element, group and attributeGroup, which both define and
reference</xs:documentation>
</xs:annotation>
<xs:attribute name="name" type="xs:NCName" />
<xs:attribute name="ref" type="xs:QName" />
</xs:attributeGroup>

http://www.w3.org/XML/1998/namespace

The namespace whose name is http://www.w3.org/XML/1998/namespace is
bound by definition to the prefix xml: according to Namespaces in XML,
W3C Recommendation 14 Jan 1999. Note that unlike all other XML
namespaces, both the name and the prefix are specified; i.e., if you
want XML 1.0 processors to recognize this namespace, you must use the
reserved prefix xml:.

xml:lang and xml:space

As of the last update of this document, the XML 1.0 Specification
defines two attribute names in this namespace:

xml:lang

Designed for identifying the human language used in the scope of the
element to which it's attached.
.
.
.

I'm no XML schema expert, but it looks to me like "name" and "ref"
are both valid attributes for an xs:attribute tag and that the XML
namespace standard requires XML processors to recognize the xml:lang
attribute. From my newbie reading, this is not something to be fixed
in JSR 222/JAXB 2.0. So, this appears to me to be a bug in JAXB.

A secondary bug is that the original error message left the name of
the offending included schema blank:

C:\java\src\foo>d:\java\jwsdp\jwsdp-1.3\jaxb\bin\xjc.bat
http://www.smsforum.net/schemas/mmap/v1.0/mmap.xsd
parsing a schema...
[ERROR] src-resolve: Cannot resolve the name 'xml:lang' to a attribute
declaration component.
line 97 of

[ERROR] src-ct.0.1: Complex Type Definition Representation Error for
type 'reasontext'. Element 'attribute' is invalid, misplaced, or occurs too
often.
line 97 of

Failed to parse a schema.
C:\java\src\foo>

In case it helps with problem diagnosis, I'm running with J2SDK 1.4.2
and have copied the endorsed jar files into the JRE lib as instructured
with JAXB 1.0.2:

C:\java\src\baz>java -version
java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

C:\java\src\baz>dir %JAVA_HOME%\jre\lib\endorsed
dir %JAVA_HOME%\jre\lib\endorsed
Volume in drive D has no label.
Volume Serial Number is 70AE-6E52

Directory of D:\java\j2se\j2sdk1.4.2\jre\lib\endorsed

03/31/2004 09:41 AM

.
03/31/2004 09:41 AM ..
03/29/2004 01:28 PM 56,619 dom.jar
03/29/2004 01:28 PM 60,963 sax.jar
03/29/2004 01:28 PM 2,823,241 xalan.jar
03/29/2004 01:28 PM 2,667,618 xercesImpl.jar
10/10/2003 06:36 PM 1,379,810 xsltc.jar
6 File(s) 6,989,573 bytes
2 Dir(s) 7,889,731,584 bytes free

C:\java\src\baz>%JWSDP_HOME%\jaxb\bin\xjc.bat -version
xjc version "1.0.2-b15-fcs"
JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build
1.0.2-b15-fcs)
C:\java\src\baz>

I'm quite interested in the resolution of this issue as I'm stopped in
my tracks on progress here. Help with resolution, whether in JAXB or
my usage of it, will be much appreciated. I did a search of existing
issues but couldn't find a duplicate.

Environment

Operating System: All
Platform: All

Affected Versions

[JWSDP1.3 (JAXB1.0.2)]

[Tomas-Kraus]

@glassfishrobot Commented
Reported by dbb

[Tomas-Kraus]

@glassfishrobot Commented
Was assigned to kohsuke

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
Also, there is a link from http://www.w3.org/XML/1998/namespace to a schema
fragment representing it: http://www.w3.org/2001/xml.xsd . Perhaps it would be
a fix to hard-code that one particular namespace-schema mapping?

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
Could you post your schemas as an attachment?
You should have received the new role that lets you do that, and if not, please
let me know.

It seems to me that the problem is you didn't import the definition for xml:lang
attribute. You are right that the prefix is bound by default, but you also
need the definition of it writtein XML Schema if you want to refer to it.

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
Changing the state to STARTED.

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
I don't have my own schema. I was trying to create Java from a public schema.
The schema that causes JAXB its problem is owned by the W3C: that is, the SOAP
schema at http://www.w3.org/2003/05/soap-envelope/soap-envelope.xsd .

The import of the XML namespace schema in the SOAP envelope schema is
done by:

<xs:import namespace="http://www.w3.org/XML/1998/namespace" />

At http://www.w3.org/XML/1998/namespace it says:

"The namespace whose name is http://www.w3.org/XML/1998/namespace is
bound by definition to the prefix xml: according to Namespaces in XML,
W3C Recommendation 14 Jan 1999. Note that unlike all other XML
namespaces, both the name and the prefix are specified; i.e., if you
want XML 1.0 processors to recognize this namespace, you must use the
reserved prefix xml:."

In the errata (http://www.w3.org/XML/xml-names-19990114-errata) for
the W3C Namespaces in XML specification
(http://www.w3.org/TR/REC-xml-names/#xmlReserved), it says:

== START ERRATA =>

Replace the Namespace Constraint "Leading XML" in section 2 with:

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.
No other prefix may be bound to this namespace name.

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. No other prefix may be bound to this namespace
name.

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.

Rationale:

This erratum clarifies several issues concerning prefixes beginning "xml".
The xmlns prefix is purely syntactic, and it makes no sense to declare it.
The xml namespace could work like any other, were it not that the xml:space
and xml:lang attributes are required to use that prefix, but it was
considered too confusing to allow anything more than declaring it normally.
The meaning of "reserved" has been made explicit.

<= END ERRATA ==

I am not an XML Schema expert, but to me all of this means:

1. the "xml" prefix does not need to be declared
2. an XML processor is supposed to know about the (definitions of)
"xml:base", "xml:lang", and "xml:space" attributes as predefined –
it is a convenience for the implementor and specification reader that
there is a schema fragment at http://www.w3.org/2001/xml.xsd .
3. It doesn't matter whether or not a schema (in this case the SOAP
envelope schema) declares (or explicitly imports) the XML namespace
schema, the XML processor should already know about the XML namespace
and its attributes.
4. There are related rules for the "xmlns" namespace.
5. It's important to note the erratum rationale about the xml namespace:
"The xml namespace could work like any other, were it not that the
xml:space and xml:lang attributes are required to use that prefix,
but it was considered too confusing to allow anything more than
declaring it normally."

I may be naive, but I'm assuming that since the SOAP schema is posted by
the W3C, that its reference to the most fundamental namespace is correct.
If I misread the specifications, I'm not sure what the process is for
notifying the W3C of a specification error.

As a side note, I think it would be a great idea to have JAXB added to
the list of tools at http://www.w3.org/XML/Schema (Castor is already).

Thanks,
David Bernstein

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:

I may be naive, but I'm assuming that since the SOAP schema is posted by
the W3C, that its reference to the most fundamental namespace is correct.
If I misread the specifications, I'm not sure what the process is for
notifying the W3C of a specification error.

Welcome to the weird world of XML Schema.

The sad truth is that according to the schema spec, it is totally legal
for a schema author to leave @schemaLocation out. And also it's totally
legal for a schema processor to fail to resolve it.

So there's no "error" involved in this. It's just that the spec is incredibly
user unfriendly.

What you can do is to fix the import declaration as follows:

<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>

If you feel like complaining about it, please write to
www-xml-schema-comments@w3.org

1. the "xml" prefix does not need to be declared

Correct.

2. an XML processor is supposed to know about the (definitions of)
"xml:base", "xml:lang", and "xml:space" attributes as predefined –
it is a convenience for the implementor and specification reader that
there is a schema fragment at http://www.w3.org/2001/xml.xsd .

You are mixing an XML parser and an XML Schema processor here. And
in particular the latter is not required to treat those attributes
any differently from other "normal" attributes.

3. It doesn't matter whether or not a schema (in this case the SOAP
envelope schema) declares (or explicitly imports) the XML namespace
schema, the XML processor should already know about the XML namespace
and its attributes.

No. See "Schema Representation Constraint: Schema Document Location Strategy"
in section 4.3.2.

4. There are related rules for the "xmlns" namespace.

?

5. It's important to note the erratum rationale about the xml namespace:
"The xml namespace could work like any other, were it not that the
xml:space and xml:lang attributes are required to use that prefix,
but it was considered too confusing to allow anything more than
declaring it normally."

Again I think you are mixing XML 1.0 processor and XML Schema processor.

As a side note, I think it would be a great idea to have JAXB added to
the list of tools at http://www.w3.org/XML/Schema (Castor is already).

Great suggestion. Thank you.

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
I agree that there's an usability issue here, but I don't think it's something
we can help. So for now, I'm closing this bug as "INVALID".

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
You've certainly convinced me that the the world of XML Schema is weird.

[For future readers, the reference to '"Schema Representation Constraint:
Schema Document Location Strategy" in section 4.3.2' is at
http://www.w3.org/TR/xmlschema-1/#schema-loc .]

You've also convinced me that it's legal for an XML Schema processor to
employ its own choice of various strategies for finding the URI for the
schema implied by a namespace.

The part where I'm not yet convinced that JAXB is XML Schema compliant
is with regard to the ability for the user to specify the schema
location for a given namespace. In the same section 4.3.2 of the XML
Schema Part 1: Structure W3C Recommendation 2 May 2001, it also says:

==> START CITATION

The composition of the complete schema for use in ·assessment· is
discussed in Layer 2: Schema Documents, Namespaces and Composition
(§4.2) above. The means used to locate appropriate schema document(s)
are processor and application dependent, subject to the following
requirements:

1. Schemas are represented on the Web in the form specified above in
Standards for representation of schemas and retrieval of schema
documents on the Web (§4.3.1);

2. The author of a document uses namespace declarations to indicate
the intended interpretation of names appearing therein; there may
or may not be a schema retrievable via the namespace
name. ACCORDINGLY WHETHER A PROCESSOR'S DEFAULT BEHAVIOR IS OR IS
NOT TO ATTEMPT SUCH DEREFERENCING, IT MUST ALWAYS PROVIDE FOR
USER-DIRECTED OVERRIDING OF THAT DEFAULT.

==> END CITATION (Emphasis of last sentence is mine.)

I read the last sentence of the citation as requiring an XML Schema
processor to allow the user to specify an override for the schema
location of any namespace declaration. I looked through the JAXB
documentation for a method to do this but could find none, so I am
(humbly) re-opening this issue. If the answer is RTFM, I will accept
a pointer to the way to do this with appreciation and humility. (Or
if I have somehow missed the point.)

The ability to override schema location specifications will, I think,
greatly encourage the use of JAXB in cases such as these where the
desire is to reference public namespaces where there is some issue
with locating the schema.

There is also still a small bug pointed out by the use of XJC on the
SMS Forum MMAP schema in the original description.

I also agree that this is a usability issue. I'd contend that it's
actually a serious usability issue because the namespace namespace
(i.e. "http://www.w3.org/XML/1998/namespace" ) is so basic to the XML
1.0 specification and is also used by the very commonly used SOAP
specification. I understand the W3C as certainly not discouraging
special-casing of the default non-overridden handling of this
particular important namespace, since in the same section as this
citation it also says:

"Note that components to be imported need not be in the form of a
·schema document·; the processor is free to access or construct
components using means of its own choosing."

Thank you,
David Bernstein

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
I tried to see if I could come up with a workaround by creating a wrapper
schema file:

C:\java\src\foo>type soap-envelope-ns.xsd

<xs:schema targetNamespace="http://www.w3.org/2003/05/soap-envelope"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:include schemaLocation="http://www.w3.org/2003/05/soap-envelope/"/>
</xs:schema>

C:\java\src\foo>

This failed to work:

C:\java\src\foo>%JWSDP_HOME%\jaxb\bin\xjc.bat file:soap-envelope-ns.xsd
parsing a schema...
[WARNING] warning: "blockDefault" attribute of is not supported
line 3 of xml.xsd

[WARNING] warning: "finalDefault" attribute of is not supported
line 3 of xml.xsd

[ERROR] a "schemaLocation" attribute is required
line 23 of

Failed to parse a schema.
C:\java\src\foo>

I believe the offending line was:
<xs:import namespace="http://www.w3.org/XML/1998/namespace" />
of http://www.w3.org/2003/05/soap-envelope , although
it seems pretty clear from
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#element-import
that it's OK to omit the schemaLocation attribute. As in the
previous comment, I believe it would be of tremendous utility
to allow the user of XJC to specify the schema location as
an override.

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
The quoted sentence is with respect to a validator and validating
an XML document, so I don't think it directly applies to xs:import.

The ability to override schema location specifications will, I think,
greatly encourage the use of JAXB in cases such as these where the
desire is to reference public namespaces where there is some issue
with locating the schema.

Nevertheless your enthusiasm convinced me that we should fix this issue.

Typically this kind of user-level "redirection" of resources have been
done by using URIResolver and EntityResolver, but unfortunately none
of those work really well with XML Schema's redirection.

So the fix doesn't give you that, but XJC will no longer fail just because
you have xs:import without @schemaLocation.

Instead, it simply ignores the import declaration. So you'll be able
to compile the schema by using the wrapper schema as you wrote, or
more simply just by:

$ xjc.bat xml.xsd soap-envelope-ns.xsd

Also, check out the -catalog switch, because this option does provide
some degree of resource redirection.
Refer to:
http://java.sun.com/webservices/docs/1.3/jaxb/xjc.html , and
http://java.sun.com/webservices/docs/1.3/jaxb/catalog.html
and also check out catalog-resolver sample in the distribution.

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
Thanks for the encouragement.

I read the documentation on using catalogs and tried but still got
the same result. I tried an OASIS TR9401 catalog:

SYSTEM "http://www.w3.org/XML/1998/namespace" "http://www.w3.org/2001/xml.xsd"
PUBLIC "http://www.w3.org/XML/1998/namespace" "http://www.w3.org/2001/xml.xsd"

as well as an OASIS XML catalog:

but I got the same results.

In com.sun.tools.xjc.reader.xmlschema.parser.XMLEntityResolverImpl,
I found:

public XMLInputSource resolveEntity(XMLResourceIdentifier r) throws
XNIException, IOException {
String publicId = r.getPublicId();
String systemId = r.getExpandedSystemId();

if(publicId==null)
// perhaps this is for resolving a schema document.
// I know this is an abuse of the public ID, but I claim
// it's still better than not providing any entity resolution
// support at all.
//
// this at least allows users to resolve
// xs:import without @schemaLocation
publicId = r.getNamespace();

which seemed to indicate that those catalogs should have worked. Is that code
from a version of xjc after 1.0.2-b15-fcs?

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
Yes, actually the code you quoted is a fairly recent one.
Try the weekly build, it should work.

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
I downloaded weekly build jaxb-ri-20040419 and reran. I still got an error,
but it manifested slightly differently:

C:\java\src\foo>d:\java\jwsdp\jwsdp-1.3\jaxb\bin\xjc.bat -extension -catalog
catalog\xml-namespace.cat http://www.w3.org/2003/05/soap-envelope/soap-
envelope.xsd

parsing a schema...
[WARNING] warning: ignored
line 32 of soap-envelope.xsd

[WARNING] warning: ignored
line 45 of soap-envelope.xsd

[WARNING] warning: ignored
line 53 of soap-envelope.xsd

[WARNING] warning: "final" attribute of is not supported
line 72 of soap-envelope.xsd

[WARNING] warning: ignored
line 136 of soap-envelope.xsd

[ERROR] undefined attribute 'xml:lang'
line 97 of soap-envelope.xsd

Failed to parse a schema.

C:\java\src\foo>

Attribute 'xml:lang' is defined in http://www.w3.org/2001/xml.xsd, which the
catalog files reference. Both OASIS TR9401 and OASIS XML catalogs give the
identical result. I'm attaching them to this report. They're identical to the
ones in the textual body of this issue.

This should be easily reproducible with command line (either catalog file):

xjc -extension -catalog xml-namespace.cat http://www.w3.org/2003/05/soap-
envelope/soap-envelope.xsd

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
Created an attachment (id=13)
OASIS TR9401 catalog

[Tomas-Kraus]

@glassfishrobot Commented
File: xml-namespace.cat
Attached By: dbb

[Tomas-Kraus]

@glassfishrobot Commented
dbb said:
Created an attachment (id=14)
OASIS XML catalog

[Tomas-Kraus]

@glassfishrobot Commented
File: xml-namespace.xct
Attached By: dbb

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
Re-opening this issue.

Based on the last few comments, looks like we need to reinvestigate this issue.

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
This time I think I really really fixed it.

To recap the issue, the mode of the failure was that you cannot compile SOAP
schema. The root cause of the issue was that SOAP schema refers to xml.xsd
without specifying the schemaLocation.

There are two ways to make it work.

1. submit both xml.xsd and soap-envelope.xsd to XJC, like this:

$ xjc http://www.w3.org/2001/xml.xsd
http://www.w3.org/2003/05/soap-envelope/soap-envelope.xsd

2. use the catalog support to help XJC resolve the schema for <xs:import
namespace="http://www.w3.org/XML/1998/namespace"/>

$ cat xml-namespace.cat
PUBLIC "http://www.w3.org/XML/1998/namespace" "http://www.w3.org/2001/xml.xsd"
$ xjc -catalog xml-namespace.cat
http://www.w3.org/2003/05/soap-envelope/soap-envelope.xsd

[Tomas-Kraus]

@glassfishrobot Commented
ebrover said:
Unfortunately I can't see this problem fixed as yet. Have just tried it with
the JAXB_RI_20050822.jar and still have the same problem.

Specifically, doing "xjc xml.xsd soap-envelope.xsd" as per option 1 in the
previous comment, I get:

parsing a schema...
[ERROR] schema_reference.4: Failed to read schema
document 'file:/C:/dev/xml.xsd', because 1) could not find the document; 2) the
document could not be read; 3) the root element of the document is not
xsd:schema.
unknown location

[ERROR] src-resolve: Cannot resolve the name 'xml:lang' to a 'attribute
declaration' component.
line 97 of file:/C:/dev/soap-envelope.txt

[ERROR] s4s-elt-invalid-content.1: The content of 'reasontext' is invalid.
Element 'attribute' is invalid, misplaced, or occurs too often.
line 97 of file:/C:/dev/soap-envelope.txt

Failed to parse a schema.

You still need to 'hack' the xml.xsd by removing the DOCTYPE line in order for
the xjc to work.

[Tomas-Kraus]

@glassfishrobot Commented
ebrover said:
Adding myself as a CC.

[Tomas-Kraus]

@glassfishrobot Commented
kohsuke said:
The error message suggests that there's something wrong with
"file:/C:/dev/xml.xsd" (I really hate this stupid error message from Xerces —
it should do a better job), could you check if this is a correct schema file?

You can also try the "-nv" option to bypass the schema correctness check done by
Xerces. This is one of the cases where JAXB RI can actually produce a beter
error message than Xerces.

[Tomas-Kraus]

@glassfishrobot Commented
ebrover said:
OK, I think you've pointed me to the issue.

I was downloading a local copy of the W3C schemas to get around proxy/firewall
issues.

The problem with that is that the xml.xsd actually has a dependency on
XMLSchema.dtd and datatypes.dtd, which it refers to only by relative path - so
these DTDs must be in the same directory as xml.xsd. If I download both DTDs
into the same local directory, then the local xjc works fine.

Similarly if I actually point xjc at the real URLs for the W3C schemas, and get
around my particular environment's proxy/firewall issues, then it works fine:

xjc [-proxy blah...] http://www.w3.org/2001/xml.xsd
http://www.w3.org/2003/05/soap-envelope/soap-envelope.xsd
parsing a schema...
compiling a schema...
org\w3_2003_05\soap_envelope\Body.java
org\w3_2003_05\soap_envelope\Detail.java
org\w3_2003_05\soap_envelope\Envelope.java
org\w3_2003_05\soap_envelope\Fault.java
org\w3_2003_05\soap_envelope\Faultcode.java
org\w3_2003_05\soap_envelope\Faultreason.java
org\w3_2003_05\soap_envelope\Header.java
org\w3_2003_05\soap_envelope\NotUnderstoodType.java
org\w3_2003_05\soap_envelope\ObjectFactory.java
org\w3_2003_05\soap_envelope\Reasontext.java
org\w3_2003_05\soap_envelope\Subcode.java
org\w3_2003_05\soap_envelope\SupportedEnvType.java
org\w3_2003_05\soap_envelope\UpgradeType.java
org\w3_2003_05\soap_envelope\package-info.java

I agree with you that the error messages are less than intuitive, but it looks
like you did fix the original issue, certainly in the 20050822 version. Sorry
for the false alarm!

[Tomas-Kraus]

@glassfishrobot Commented
Marked as fixed on Tuesday, August 23rd 2005, 2:00:32 pm

[Tomas-Kraus]

@glassfishrobot Commented
This issue was imported from java.net JIRA JAXB-15

[Tomas-Kraus]

• Issue Imported From: can't parse W3 SOAP 2003-05 envelope XML schema: "xml:lang" attr ref javaee/jaxb-v2#15
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @glassfishrobot
• Original Issue Closed By:@glassfishrobot