Shoot. After changing the connector and security schema to point to the
2001 version of xml.xsd, found a bug in EMF which Ed responded with:
...The XML namespace schema itself was changed. :-( As a result, we
needed to regenerate that package to support the change changes. That
work was done with:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=110340 A workaround is to
redirect the schemaLocation for the xml.xsd to an older version.
So, since we've been referencing the deprecated xml.xsd all this time
anyways with any concerns of moving up, would it be a huge issue if I
referenced back to that xsd instead of http://www.w3.org/2001/xml.xsd?
Sorry :)
Sachin
Sachin Patel wrote:
Yes, you are correct. Those two files which are in openejb need to be
fixed as well, but since those are in a different repository someone
else will need to fix them.
Matt, David J, or David B, would you mind putting in the same import
to resolve xml:lang for these two files?
geronimo-service-1.0.xsd is a different issue. The validation error
is as described below...
The namespace attribute
'http://geronimo.apache.org/xml/ns/deployment-1.0' of an <import>
element information item must not be the same as the targetNamespace
of the schema it exists in. geronimo-service-1.0.xsd a/schema
line 35 November 30, 2005 2:56:01 PM 17
As far as your error, I can't verify due to the itests not running at
the moment. Make your schemaLocation use the http://....xml.xsd, run
clean at the root of open ejb, and rerun to ensure the new xmlbeans
classes are being regenerated.
Sachin
Brian Bonner wrote:
I added:
<xsd:import namespace="http://www.w3.org/XML/1998/namespace";
schemaLocation="xml.xsd"/>
<xsd:import
namespace="http://geronimo.apache.org/xml/ns/security-1.1";
schemaLocation="geronimo-security-1.1.xsd"/>
to corba-tss-config-2.0.xsd
but it's failing on:
Testsuite: org.openejb.corba.security.config.tss.TSSConfigEditorTest
Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 1.75 sec
Testcase:
testSimple1(org.openejb.corba.security.config.tss.TSSConfigEditorTest):
Caused
an ERROR
Cannot resolve type for handle
_XY_Q=lang|[EMAIL PROTECTED]://www.w3.org/XML/1998/namespace
(schemaorg_apache_xmlbeans.system.sBCFA77F9E613DB031018700055C2136C.descriptiontypeb480type)
- code 13
org.apache.xmlbeans.SchemaTypeLoaderException: Cannot resolve type for
handle _XY_Q=lang|[EMAIL PROTECTED]://www.w3.org/XML/1998/namespace
(schemaorg_apache_xmlbeans.system.sBCFA77F9E613DB031018700055C2136C.descriptiontypeb480type)
- code 13
at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readHandle(SchemaTypeSystemImpl.java:2000)
at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readTypeRef(SchemaTypeSystemImpl.java:2074)
at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.loadAttribute(SchemaTypeSystemImpl.java:2891)
at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readAttributeData(SchemaTypeSystemImpl.java:2883)
at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.finishLoadingType(SchemaTypeSystemImpl.java:2500)
at
org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.resolveHandle(SchemaTypeSystemImpl.java:3476)
at
org.apache.xmlbeans.SchemaComponent$Ref.getComponent(SchemaComponent.java:104)
at org.apache.xmlbeans.SchemaType$Ref.get(SchemaType.java:872)
at
org.apache.xmlbeans.impl.schema.SchemaParticleImpl.getType(SchemaParticleImpl.java:194)
at
org.apache.xmlbeans.impl.validator.Validator.beginEvent(Validator.java:395)
at
org.apache.xmlbeans.impl.validator.Validator.nextEvent(Validator.java:247)
at
org.apache.xmlbeans.impl.store.Validate.emitEvent(Validate.java:172)
at org.apache.xmlbeans.impl.store.Validate.process(Validate.java:79)
at org.apache.xmlbeans.impl.store.Validate.<init>(Validate.java:39)
at org.apache.xmlbeans.impl.store.Xobj.validate(Xobj.java:1780)
at
org.apache.xmlbeans.impl.values.XmlObjectBase.validate(XmlObjectBase.java:346)
at
org.apache.geronimo.schema.SchemaConversionUtils.validateDD(SchemaConversionUtils.java:593)
at
org.openejb.corba.security.config.tss.TSSConfigEditor.getValue(TSSConfigEditor.java:117)
at
org.openejb.corba.security.config.tss.TSSConfigEditorTest.testSimple1(TSSConfigEditorTest.java:104)
On 11/30/05, Brian Bonner <[EMAIL PROTECTED]> wrote:
Jeff, Sachin,
btw, I caught a problem in the corba stuff after the build:
with: corba-tss-config-2.0.xsd
This has a similar import problem that I haven't yet resolved which is
causing my build to fail.
geronimo-service-1.0.xsd also has problems, but they're not affecting
me right now.
Brian
On 11/30/05, Brian Bonner <[EMAIL PROTECTED]> wrote:
Sachin,
I pulled the xsd from here: http://www.w3.org/2001/xml.xsd
Brian
On 11/30/05, Sachin Patel <[EMAIL PROTECTED]> wrote:
The patch is incorrect since it uses the deprecated xml.xsd, I'm
about
to fix it using the correct schema location, verify xmlbeans and emf
code gen both work, and then commit.
Thanks,
Sachin.
Brian Bonner wrote:
Jeff,
I've fixed the patch I submitted at:
http://issues.apache.org/jira/browse/GERONIMO-1247
I'm not sure which patch you refer to here, but I built Geronimo
using
this patch which also fixes the schema issues and makes xmlbeans
"happy".
Maybe someone can test it in idea. It seems to fix issues in
Eclipse.
Thanks,
Brian
On 11/30/05, Jeff Genender <[EMAIL PROTECTED]> wrote:
Sachin Patel wrote:
I personally think this fix should go in, not because a
particular IDE
or modeling tool does not tollerate it, but because its
recommend as
best practice or required by specification. So if its true
that imports
aren't transitive, then the import should be added.
I have to agree with DJ on this one. If its us, then obviously
we need
to fix it. If its eclipse, then they need to fix it. Based on
your
statement, do you have a copy of the blurb that states the
imports do
not follow through from other imports?
The fact it works in other IDEs and XMLBeans parses it, leads me to
believe its an Eclipse issue. In fact running a schema
validation in
Oxygen answers it as fully validated...and I tend to believe
Oxygen as
they are one of the leaders in XML/XSD toolsets.
However, I am more than happy to change my views if this is truly a
specification issue.
Also, I tried that import in the security XSD, and it does not
seem to
get rid of the error.
If we do need to include the import, your patch needs to be this:
<xs:import namespace="http://www.w3.org/XML/1998/namespace";
schemaLocation="http://www.w3.org/2001/xml.xsd";>
Your patch currently references a deprecated xsd.
Jeff
Sachin
David Jencks wrote:
On Nov 29, 2005, at 12:43 PM, Jeff Genender wrote:
Is XMLBeans able to work with it in its current form?
Yes, and I admit to ignoring this problem since I tend to trust
xmlbeans as the final arbiter of xml schema compliance. I
think we
might want to ask on the xmlbeans list for their opinion.
Right now I
don't have the bandwidth for it.
thanks
david jencks
IntelliJ seems to accept it. I am just getting the error in
Eclipse...this is why this concerns me a little.
Sachin Patel wrote:
Jeff,
According to Ed, the schema isn't valid without the import.
See his
response below.
-------- Original Message --------
Subject: Re: EMF can't resolve xml:lang in schema
Date: Tue, 29 Nov 2005 11:40:34 -0500
From: Ed Merks <[EMAIL PROTECTED]>
Organization: EclipseCorner
Newsgroups: eclipse.tools.emf
References: <[EMAIL PROTECTED]>
Sachin,
Imports in XML Schema are not transitive. I.e., importing a
schema
that
in turn contains imports doesn't mean you have indirectly
imported all
those too. So if you use xml:lang in your schema, your
schema must
contain an import for that. Without that import, your
schema isn't
valid.
Jeff Genender wrote:
I don't think you want to import this...the 1998 schema is
supposed
to be redirected to the 2001 version. It should already be
imported from the reference to
http://www.w3.org/2001/XMLSchema at
he top.
Are you having problems building from the command liine or
from
within Eclipse.
Apparently there seems to be an issue in Eclipse with the
subversion plugin that causes. I have not looked heavily
into this
issue...it can be found here:
http://www.eclipse.org/newsportal/article.php?id=1390&group=eclipse.technology.xsd
Jeff
Sachin Patel wrote:
Yes, I see this validation error as well. There is a
similar error
also with geronimo-security-1.0.xsd. There is already an
existing
jira opened for this. In the tools, this problem prevents
EMF
code generation from completing and as a workaround I
patch the
schema prior to codegen by including the following import for
geronimo-connector-1.0.xsd.
<xs:import namespace="http://www.w3.org/XML/1998/namespace";
schemaLocation="xml.xsd"/>
Brian Bonner wrote:
I'm getting an error in the geronimo-connector-1.0.xsd,
but I'm not
sure if it's because of Eclipse's WTP or something else.
here's the error:
src-resolve.4.2: Error resolving component 'xml:lang'. It
was
detected
that 'xml:lang' is in namespace
'http://www.w3.org/XML/1998/namespace', but components
from this
namespace are not referenceable from schema document
'file:///C:/workspace_paraware/testschema/schema/geronimo-connector-1.0.xsd'.
If this is the incorrect namespace, perhaps the prefix of
'xml:lang'
needs to be changed. If this is the correct namespace,
then an
appropriate 'import' tag should be added to
'file:///C:/workspace_paraware/testschema/schema/geronimo-connector-1.0.xsd'.
it's occurring in line 391:
<xs:complexType name="descriptionType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/> <!--
right here
-->
</xs:extension>
</xs:simpleContent>
</xs:complexType>
Is anyone else seeing this?
Brian
