Home » Archived » XML Schema Definition (XSD) » Weird namespaces when moving objects between XSD schemas
|
| Re: Weird namespaces when moving objects between XSD schemas [message #28216 is a reply to message #28174] |
Thu, 04 September 2003 18:32   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------3A07646349EF55C6534EDB66
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
In XSDConcreteComponentImpl there is this method:
protected String niceCreateNamespaceAttribute(String namespace)
{
XSDSchema xsdSchema = getSchema();
if (namespace == null)
{
namespace = "";
}
if (xsdSchema != null && xsdSchema.getElement() != null)
{
Element schemaElement = xsdSchema.getElement();
if (XSDConstants.isSchemaForSchemaNamespace(namespace))
{
if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000, "xsd"))
{
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);
return "xsd";
}
}
String qualifier = "Q";
int count = 1;
while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" + qualifier + count))
{
++count;
}
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
qualifier + count, namespace);
return qualifier + count;
}
else
{
return null;
}
}
It's called from one place that looks like this:
String qualifier = XSDConstants.lookupQualifier(element, namespace);
if (qualifier == null)
{
qualifier = niceCreateNamespaceAttribute(namespace);
}
So it should create a new xmlns declaration only if there isn't already one.
I'm not sure how the duplication can happen given this algorithm...
Hayden Marchant wrote:
> I am merging the contents of schemas by iterating over the elements of the
> referred schemas of a certain base schema and adding all the contents of
> them into the base schema. Here is a snippet of my code:
>
> XSDSchema primaryXSDSchema = getEclipseXSDSchema();
>
> for (Iterator iterator = fReferencedXsdSchemas.iterator();
> iterator.hasNext();) {
> XSDSchema referredSchema = (XSDSchema) iterator.next();
>
> primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> }
>
> This code works nicely. However, sometimes when I run this code, I get a
> weird phenomenom. The root of the schema becomes:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> xmlns="http://ACORD.org/Standards/Life/2"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> I have no idea where this Q1 comes from, but lots of the xsd elements from
> the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> whole schema is Q1. e.g. <Q1:schema>.....
>
> Also, when validating this schema, all elements that are of type
> <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> seems to have been some duplication of XMLSchema namespaces when objects
> were moved over.
>
> Any idea what I may be doing wrong?
>
> Thanks
--------------3A07646349EF55C6534EDB66
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>In XSDConcreteComponentImpl there is this method:
<p><tt> protected String niceCreateNamespaceAttribute(String namespace)</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (namespace == null)</tt>
<br><tt> {</tt>
<br><tt> namespace = "";</tt>
<br><tt> }</tt>
<br><tt> if (xsdSchema != null && xsdSchema.getElement()
!= null)</tt>
<br><tt> {</tt>
<br><tt> Element schemaElement = xsdSchema.getElement();</tt>
<br><tt> if (XSDConstants.isSchemaForSchemaNamespace(namespace))</tt>
<br><tt> {</tt>
<br><tt> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))</tt>
<br><tt> {</tt>
<br><tt> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);</tt>
<br><tt> return "xsd";</tt>
<br><tt> }</tt>
<br><tt> }</tt><tt></tt>
<p><tt> String qualifier = "Q";</tt>
<br><tt> int count = 1;</tt>
<br><tt> while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" + qualifier + count))</tt>
<br><tt> {</tt>
<br><tt> ++count;</tt>
<br><tt> }</tt>
<br><tt> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" + qualifier + count, namespace);</tt>
<br><tt> return qualifier + count;</tt>
<br><tt> }</tt>
<br><tt> else</tt>
<br><tt> {</tt>
<br><tt> return null;</tt>
<br><tt> }</tt>
<br><tt> }</tt>
<p>It's called from one place that looks like this:
<p> String qualifier = XSDConstants.lookupQualifier(element,
namespace);
<br> if (qualifier == null)
<br> {
<br> qualifier =
niceCreateNamespaceAttribute(namespace);
<br> }
<p>So it should create a new xmlns declaration only if there isn't already
one.
<p>I'm not sure how the duplication can happen given this algorithm...
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>I am merging the contents of schemas by iterating
over the elements of the
<br>referred schemas of a certain base schema and adding all the contents
of
<br>them into the base schema. Here is a snippet of my code:
<p> XSDSchema primaryXSDSchema
= getEclipseXSDSchema();
<p> for (Iterator iterator =
fReferencedXsdSchemas.iterator();
<br>iterator.hasNext();) {
<br>
XSDSchema referredSchema = (XSDSchema) iterator.next();
<p> primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
<br> }
<p>This code works nicely. However, sometimes when I run this code, I get
a
<br>weird phenomenom. The root of the schema becomes:
<p><?xml version="1.0" encoding="UTF-8"?>
<br><xsd:schema targetNamespace="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>xmlns:Q1="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>xmlns="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>xmlns:xsd="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>I have no idea where this Q1 comes from, but lots of the xsd elements
from
<br>the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes
the
<br>whole schema is Q1. e.g. <Q1:schema>.....
<p>Also, when validating this schema, all elements that are of type
<br><Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
There
<br>seems to have been some duplication of XMLSchema namespaces when objects
<br>were moved over.
<p>Any idea what I may be doing wrong?
<p>Thanks</blockquote>
</html>
--------------3A07646349EF55C6534EDB66--
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #28293 is a reply to message #28216] |
Sat, 06 September 2003 19:36 |
 Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Ed,
Shouldn't the code read:
if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))
{
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);
}
return "xsd";
as opposed to :
if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))
{
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);
return "xsd";
}
i.e. when I debugged the code, I got to this method call. My schema
element does have the relevant attribute set to 'xsd'. So the code does
not need to call setAttributeNS and should return nicely. However, it
carries on a resets a duplicate namespace for XSD.
In my opinion, it's a simple bug - I made a local change in my copy of the
eclipse src and it sort of solved it. Am I talking sense?
I am still not clear of the case that the code is ever supposed to get to
make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
more correct to check ALL of the attributes, and if there exists an
attribute that has a valid value for
XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
of that attribute should be returned as the namespace for that method.
Ed Merks wrote:
> Hayden,
> In XSDConcreteComponentImpl there is this method:
> protected String niceCreateNamespaceAttribute(String namespace)
> {
> XSDSchema xsdSchema = getSchema();
> if (namespace == null)
> {
> namespace = "";
> }
> if (xsdSchema != null && xsdSchema.getElement() != null)
> {
> Element schemaElement = xsdSchema.getElement();
> if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> {
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> return "xsd";
> }
> }
> String qualifier = "Q";
> int count = 1;
> while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:" + qualifier + count))
> {
> ++count;
> }
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
> qualifier + count, namespace);
> return qualifier + count;
> }
> else
> {
> return null;
> }
> }
> It's called from one place that looks like this:
> String qualifier = XSDConstants.lookupQualifier(element, namespace);
> if (qualifier == null)
> {
> qualifier = niceCreateNamespaceAttribute(namespace);
> }
> So it should create a new xmlns declaration only if there isn't already one.
> I'm not sure how the duplication can happen given this algorithm...
> Hayden Marchant wrote:
> > I am merging the contents of schemas by iterating over the elements of the
> > referred schemas of a certain base schema and adding all the contents of
> > them into the base schema. Here is a snippet of my code:
> >
> > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> >
> > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > iterator.hasNext();) {
> > XSDSchema referredSchema = (XSDSchema) iterator.next();
> >
> > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > }
> >
> > This code works nicely. However, sometimes when I run this code, I get a
> > weird phenomenom. The root of the schema becomes:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://ACORD.org/Standards/Life/2"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > I have no idea where this Q1 comes from, but lots of the xsd elements from
> > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > whole schema is Q1. e.g. <Q1:schema>.....
> >
> > Also, when validating this schema, all elements that are of type
> > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > seems to have been some duplication of XMLSchema namespaces when objects
> > were moved over.
> >
> > Any idea what I may be doing wrong?
> >
> > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #28331 is a reply to message #28293] |
Sun, 07 September 2003 13:46 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
As I indicated in my previous note, the method is called from a guard:
Hayden Marchant wrote:
> Ed,
>
> Shouldn't the code read:
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> }
> return "xsd";
>
> as opposed to :
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> return "xsd";
> }
>
> i.e. when I debugged the code, I got to this method call. My schema
> element does have the relevant attribute set to 'xsd'. So the code does
> not need to call setAttributeNS and should return nicely. However, it
> carries on a resets a duplicate namespace for XSD.
>
> In my opinion, it's a simple bug - I made a local change in my copy of the
> eclipse src and it sort of solved it. Am I talking sense?
>
> I am still not clear of the case that the code is ever supposed to get to
> make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> more correct to check ALL of the attributes, and if there exists an
> attribute that has a valid value for
> XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> of that attribute should be returned as the namespace for that method.
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In XSDConcreteComponentImpl there is this method:
>
> > protected String niceCreateNamespaceAttribute(String namespace)
> > {
> > XSDSchema xsdSchema = getSchema();
> > if (namespace == null)
> > {
> > namespace = "";
> > }
> > if (xsdSchema != null && xsdSchema.getElement() != null)
> > {
> > Element schemaElement = xsdSchema.getElement();
> > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > {
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
>
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > return "xsd";
> > }
> > }
>
> > String qualifier = "Q";
> > int count = 1;
> > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:" + qualifier + count))
> > {
> > ++count;
> > }
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
> > qualifier + count, namespace);
> > return qualifier + count;
> > }
> > else
> > {
> > return null;
> > }
> > }
>
> > It's called from one place that looks like this:
>
> > String qualifier = XSDConstants.lookupQualifier(element, namespace);
> > if (qualifier == null)
> > {
> > qualifier = niceCreateNamespaceAttribute(namespace);
> > }
>
> > So it should create a new xmlns declaration only if there isn't already one.
>
> > I'm not sure how the duplication can happen given this algorithm...
>
> > Hayden Marchant wrote:
>
> > > I am merging the contents of schemas by iterating over the elements of the
> > > referred schemas of a certain base schema and adding all the contents of
> > > them into the base schema. Here is a snippet of my code:
> > >
> > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > >
> > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > iterator.hasNext();) {
> > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > >
> > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > }
> > >
> > > This code works nicely. However, sometimes when I run this code, I get a
> > > weird phenomenom. The root of the schema becomes:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > xmlns="http://ACORD.org/Standards/Life/2"
> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > I have no idea where this Q1 comes from, but lots of the xsd elements from
> > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > whole schema is Q1. e.g. <Q1:schema>.....
> > >
> > > Also, when validating this schema, all elements that are of type
> > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > seems to have been some duplication of XMLSchema namespaces when objects
> > > were moved over.
> > >
> > > Any idea what I may be doing wrong?
> > >
> > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #28368 is a reply to message #28293] |
Sun, 07 September 2003 14:03 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------D85D31BE0E6A8FCC58FEE674
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
Sorry for the earlier miss send.
As I indicated in my previous note, the method is called from a guard:
protected void niceSetAttributeURIValue(Element element, String attribute,
String uriList)
{
....
String qualifier = XSDConstants.lookupQualifier(element, namespace);
if (qualifier == null)
{
qualifier = niceCreateNamespaceAttribute(namespace);
}
So if there is an xmlns declaration already for the namespace, it should be used.
I.e., all the attributes are checked as you suggest.
I have a strong suspicion that the DOM elements you are manipulating were created
without namespace awareness. Could that be the case?
The xsd prefix is not so presumptuous considering the Primer example:
http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
This special case is only there to avoid the use "Q" for the special schema
namespace itself.
The change you show doesn't look right. The code is written to avoid using "xsd"
if it's being used for something else already. A Q prefix will be introduced in
the case of adding a declaration with a namespace not previously used or in the
case that "xsd" is used for something else...
The important question here is why is the guarded failing to find an existing
xmlns declaration? I suspect it has to do with namespace awareness in how the DOM
was constructed...
Hayden Marchant wrote:
> Ed,
>
> Shouldn't the code read:
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> }
> return "xsd";
>
> as opposed to :
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> return "xsd";
> }
>
> i.e. when I debugged the code, I got to this method call. My schema
> element does have the relevant attribute set to 'xsd'. So the code does
> not need to call setAttributeNS and should return nicely. However, it
> carries on a resets a duplicate namespace for XSD.
>
> In my opinion, it's a simple bug - I made a local change in my copy of the
> eclipse src and it sort of solved it. Am I talking sense?
>
> I am still not clear of the case that the code is ever supposed to get to
> make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> more correct to check ALL of the attributes, and if there exists an
> attribute that has a valid value for
> XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> of that attribute should be returned as the namespace for that method.
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In XSDConcreteComponentImpl there is this method:
>
> > protected String niceCreateNamespaceAttribute(String namespace)
> > {
> > XSDSchema xsdSchema = getSchema();
> > if (namespace == null)
> > {
> > namespace = "";
> > }
> > if (xsdSchema != null && xsdSchema.getElement() != null)
> > {
> > Element schemaElement = xsdSchema.getElement();
> > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > {
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
>
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > return "xsd";
> > }
> > }
>
> > String qualifier = "Q";
> > int count = 1;
> > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:" + qualifier + count))
> > {
> > ++count;
> > }
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
> > qualifier + count, namespace);
> > return qualifier + count;
> > }
> > else
> > {
> > return null;
> > }
> > }
>
> > It's called from one place that looks like this:
>
> > String qualifier = XSDConstants.lookupQualifier(element, namespace);
> > if (qualifier == null)
> > {
> > qualifier = niceCreateNamespaceAttribute(namespace);
> > }
>
> > So it should create a new xmlns declaration only if there isn't already one.
>
> > I'm not sure how the duplication can happen given this algorithm...
>
> > Hayden Marchant wrote:
>
> > > I am merging the contents of schemas by iterating over the elements of the
> > > referred schemas of a certain base schema and adding all the contents of
> > > them into the base schema. Here is a snippet of my code:
> > >
> > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > >
> > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > iterator.hasNext();) {
> > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > >
> > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > }
> > >
> > > This code works nicely. However, sometimes when I run this code, I get a
> > > weird phenomenom. The root of the schema becomes:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > xmlns="http://ACORD.org/Standards/Life/2"
> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > I have no idea where this Q1 comes from, but lots of the xsd elements from
> > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > whole schema is Q1. e.g. <Q1:schema>.....
> > >
> > > Also, when validating this schema, all elements that are of type
> > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > seems to have been some duplication of XMLSchema namespaces when objects
> > > were moved over.
> > >
> > > Any idea what I may be doing wrong?
> > >
> > > Thanks
--------------D85D31BE0E6A8FCC58FEE674
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>Sorry for the earlier miss send.
<p>As I indicated in my previous note, the method is called from a guard:
<p> protected void niceSetAttributeURIValue(Element element, String
attribute, String uriList)
<br> {
<br> ....
<br> <font color="#CC0000">String
qualifier = XSDConstants.lookupQualifier(element, namespace);</font>
<br> if (qualifier == null)
<br> {
<br> qualifier =
niceCreateNamespaceAttribute(namespace);
<br> }
<p>So if there is an xmlns declaration already for the namespace, it should
be used. I.e., all the attributes are checked as you suggest.
<p>I have a strong suspicion that the DOM elements you are manipulating
were created without namespace awareness. Could that be the case?
<p>The xsd prefix is not so presumptuous considering the Primer example:
<blockquote><a href=" http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema"> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema</a></blockquote>
This special case is only there to avoid the use "Q" for the special schema
namespace itself.
<p>The change you show doesn't look right. The code is written to
avoid using "xsd" if it's being used for something else already.
A Q prefix will be introduced in the case of adding a declaration with
a namespace not previously used or in the case that "xsd" is used for something
else...
<p>The important question here is why is the guarded failing to find an
existing xmlns declaration? I suspect it has to do with namespace
awareness in how the DOM was constructed...
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>Ed,
<p>Shouldn't the code read:
<p> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xsd"))
<br> {
<br> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xmlns:xsd", namespace);
<br> }
<br> return "xsd";
<p>as opposed to :
<p> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xsd"))
<br> {
<br> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xmlns:xsd", namespace);
<br> return "xsd";
<br> }
<p>i.e. when I debugged the code, I got to this method call. My schema
<br>element does have the relevant attribute set to 'xsd'. So the code
does
<br>not need to call setAttributeNS and should return nicely. However,
it
<br>carries on a resets a duplicate namespace for XSD.
<p>In my opinion, it's a simple bug - I made a local change in my copy
of the
<br>eclipse src and it sort of solved it. Am I talking sense?
<p>I am still not clear of the case that the code is ever supposed to get
to
<br>make a "Q" XSD namespace. Also isn't it a bit presumptious that the
XSD
<br>namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it
be
<br>more correct to check ALL of the attributes, and if there exists an
<br>attribute that has a valid value for
<br>XSDConstants.isSchemaForSchemaNamespace() then that's the one and the
name
<br>of that attribute should be returned as the namespace for that method.
<p>Ed Merks wrote:
<p>> Hayden,
<p>> In XSDConcreteComponentImpl there is this method:
<p>> protected String niceCreateNamespaceAttribute(String namespace)
<br>> {
<br>> XSDSchema xsdSchema = getSchema();
<br>> if (namespace == null)
<br>> {
<br>> namespace = "";
<br>> }
<br>> if (xsdSchema != null && xsdSchema.getElement()
!= null)
<br>> {
<br>> Element schemaElement = xsdSchema.getElement();
<br>> if (XSDConstants.isSchemaForSchemaNamespace(namespace))
<br>> {
<br>> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xsd"))
<p>> {
<br>> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>> "xmlns:xsd", namespace);
<br>> return
"xsd";
<br>> }
<br>> }
<p>> String qualifier = "Q";
<br>> int count = 1;
<br>> while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>> "xmlns:" + qualifier + count))
<br>> {
<br>> ++count;
<br>> }
<br>> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" +
<br>> qualifier + count, namespace);
<br>> return qualifier + count;
<br>> }
<br>> else
<br>> {
<br>> return null;
<br>> }
<br>> }
<p>> It's called from one place that looks like this:
<p>> String qualifier =
XSDConstants.lookupQualifier(element, namespace);
<br>> if (qualifier ==
null)
<br>> {
<br>> qualifier
= niceCreateNamespaceAttribute(namespace);
<br>> }
<p>> So it should create a new xmlns declaration only if there isn't already
one.
<p>> I'm not sure how the duplication can happen given this algorithm...
<p>> Hayden Marchant wrote:
<p>> > I am merging the contents of schemas by iterating over the elements
of the
<br>> > referred schemas of a certain base schema and adding all the contents
of
<br>> > them into the base schema. Here is a snippet of my code:
<br>> >
<br>> > XSDSchema primaryXSDSchema
= getEclipseXSDSchema();
<br>> >
<br>> > for (Iterator iterator
= fReferencedXsdSchemas.iterator();
<br>> > iterator.hasNext();) {
<br>> >
XSDSchema referredSchema = (XSDSchema) iterator.next();
<br>> >
<br>> > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
<br>> > }
<br>> >
<br>> > This code works nicely. However, sometimes when I run this code,
I get a
<br>> > weird phenomenom. The root of the schema becomes:
<br>> >
<br>> > <?xml version="1.0" encoding="UTF-8"?>
<br>> > <xsd:schema targetNamespace="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>> > xmlns:Q1="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > xmlns="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>> > xmlns:xsd="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >
<br>> > I have no idea where this Q1 comes from, but lots of the xsd elements
from
<br>> > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes
the
<br>> > whole schema is Q1. e.g. <Q1:schema>.....
<br>> >
<br>> > Also, when validating this schema, all elements that are of type
<br>> > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
There
<br>> > seems to have been some duplication of XMLSchema namespaces when
objects
<br>> > were moved over.
<br>> >
<br>> > Any idea what I may be doing wrong?
<br>> >
<br>> > Thanks</blockquote>
</html>
--------------D85D31BE0E6A8FCC58FEE674--
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #30389 is a reply to message #28368] |
Mon, 29 September 2003 17:18 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
I'm still getting another related problem - in fact, I have cornered it
down quite a specific scenario:
1. Load a simple XSDSchema, for example:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
xmlns="http://ACORD.org/Standards/Life/2"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xsd:complexType name="INQUIRY_LEVEL_CODES">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="tc" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:nonNegativeInteger">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value="3"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:element name="VendorName">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
The schema is valid 100% and has no diagnostics.
2. Load an XSDSchema2 that has nested includes.
3. Remove elements from both this schemas and some of the includes (if I
only remove from this schema and NOT from includes, bug does not happen).
4. dump the pruned main XSDSchema2 to an OutputStream.
5. Repeat step 1 - this step the same schema has the following diagnostic:
Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
unresolved.
Basically, Eclipse XSD seems to break after removing items from nested
schemas. I cna't isolate this bug to such an extent that I can send a
reproducable code but above is that basic scenario. Has anyone come across
something like this?
Thanks
Ed Merks wrote:
> Hayden,
> Sorry for the earlier miss send.
> As I indicated in my previous note, the method is called from a guard:
> protected void niceSetAttributeURIValue(Element element, String attribute,
> String uriList)
> {
> ....
> String qualifier = XSDConstants.lookupQualifier(element, namespace);
> if (qualifier == null)
> {
> qualifier = niceCreateNamespaceAttribute(namespace);
> }
> So if there is an xmlns declaration already for the namespace, it should be
used.
> I.e., all the attributes are checked as you suggest.
> I have a strong suspicion that the DOM elements you are manipulating were
created
> without namespace awareness. Could that be the case?
> The xsd prefix is not so presumptuous considering the Primer example:
> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> This special case is only there to avoid the use "Q" for the special schema
> namespace itself.
> The change you show doesn't look right. The code is written to avoid using
"xsd"
> if it's being used for something else already. A Q prefix will be
introduced in
> the case of adding a declaration with a namespace not previously used or in
the
> case that "xsd" is used for something else...
> The important question here is why is the guarded failing to find an existing
> xmlns declaration? I suspect it has to do with namespace awareness in how
the DOM
> was constructed...
> Hayden Marchant wrote:
> > Ed,
> >
> > Shouldn't the code read:
> >
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xsd"))
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > }
> > return "xsd";
> >
> > as opposed to :
> >
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xsd"))
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > return "xsd";
> > }
> >
> > i.e. when I debugged the code, I got to this method call. My schema
> > element does have the relevant attribute set to 'xsd'. So the code does
> > not need to call setAttributeNS and should return nicely. However, it
> > carries on a resets a duplicate namespace for XSD.
> >
> > In my opinion, it's a simple bug - I made a local change in my copy of the
> > eclipse src and it sort of solved it. Am I talking sense?
> >
> > I am still not clear of the case that the code is ever supposed to get to
> > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > more correct to check ALL of the attributes, and if there exists an
> > attribute that has a valid value for
> > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> > of that attribute should be returned as the namespace for that method.
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > In XSDConcreteComponentImpl there is this method:
> >
> > > protected String niceCreateNamespaceAttribute(String namespace)
> > > {
> > > XSDSchema xsdSchema = getSchema();
> > > if (namespace == null)
> > > {
> > > namespace = "";
> > > }
> > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > {
> > > Element schemaElement = xsdSchema.getElement();
> > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > {
> > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xsd"))
> >
> > > {
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:xsd", namespace);
> > > return "xsd";
> > > }
> > > }
> >
> > > String qualifier = "Q";
> > > int count = 1;
> > > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:" + qualifier + count))
> > > {
> > > ++count;
> > > }
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:"
+
> > > qualifier + count, namespace);
> > > return qualifier + count;
> > > }
> > > else
> > > {
> > > return null;
> > > }
> > > }
> >
> > > It's called from one place that looks like this:
> >
> > > String qualifier = XSDConstants.lookupQualifier(element,
namespace);
> > > if (qualifier == null)
> > > {
> > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > }
> >
> > > So it should create a new xmlns declaration only if there isn't already
one.
> >
> > > I'm not sure how the duplication can happen given this algorithm...
> >
> > > Hayden Marchant wrote:
> >
> > > > I am merging the contents of schemas by iterating over the elements of
the
> > > > referred schemas of a certain base schema and adding all the contents
of
> > > > them into the base schema. Here is a snippet of my code:
> > > >
> > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > >
> > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > iterator.hasNext();) {
> > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > >
> > > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > }
> > > >
> > > > This code works nicely. However, sometimes when I run this code, I get
a
> > > > weird phenomenom. The root of the schema becomes:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > >
> > > > I have no idea where this Q1 comes from, but lots of the xsd elements
from
> > > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > >
> > > > Also, when validating this schema, all elements that are of type
> > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > > seems to have been some duplication of XMLSchema namespaces when
objects
> > > > were moved over.
> > > >
> > > > Any idea what I may be doing wrong?
> > > >
> > > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #30461 is a reply to message #30389] |
Mon, 29 September 2003 18:30 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
There is a significant hole in the editing support that editing changes don't
propagate across schemas. So if you delete something from an included schema, the
including schema won't know about that. You should restrict editing to the "root"
schema, i.e., the one that includes and imports the others; or you need to rebuild
model for the schemas affected by the change. There should probably be a method on
XSDSchema that forces such a recomputation to happen...
Hayden Marchant wrote:
> I'm still getting another related problem - in fact, I have cornered it
> down quite a specific scenario:
>
> 1. Load a simple XSDSchema, for example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> xmlns="http://ACORD.org/Standards/Life/2"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xsd:complexType name="INQUIRY_LEVEL_CODES">
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="tc" use="required">
> <xsd:simpleType>
> <xsd:restriction base="xsd:nonNegativeInteger">
> <xsd:enumeration value="1"/>
> <xsd:enumeration value="2"/>
> <xsd:enumeration value="3"/>
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:attribute>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> <xsd:element name="VendorName">
> <xsd:complexType>
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> </xsd:element>
> </xsd:schema>
>
> The schema is valid 100% and has no diagnostics.
>
> 2. Load an XSDSchema2 that has nested includes.
> 3. Remove elements from both this schemas and some of the includes (if I
> only remove from this schema and NOT from includes, bug does not happen).
> 4. dump the pruned main XSDSchema2 to an OutputStream.
> 5. Repeat step 1 - this step the same schema has the following diagnostic:
>
> Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
> unresolved.
>
> Basically, Eclipse XSD seems to break after removing items from nested
> schemas. I cna't isolate this bug to such an extent that I can send a
> reproducable code but above is that basic scenario. Has anyone come across
> something like this?
>
> Thanks
>
> Ed Merks wrote:
>
> > Hayden,
>
> > Sorry for the earlier miss send.
>
> > As I indicated in my previous note, the method is called from a guard:
>
> > protected void niceSetAttributeURIValue(Element element, String attribute,
> > String uriList)
> > {
> > ....
> > String qualifier = XSDConstants.lookupQualifier(element, namespace);
> > if (qualifier == null)
> > {
> > qualifier = niceCreateNamespaceAttribute(namespace);
> > }
>
> > So if there is an xmlns declaration already for the namespace, it should be
> used.
> > I.e., all the attributes are checked as you suggest.
>
> > I have a strong suspicion that the DOM elements you are manipulating were
> created
> > without namespace awareness. Could that be the case?
>
> > The xsd prefix is not so presumptuous considering the Primer example:
>
> > http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
>
> > This special case is only there to avoid the use "Q" for the special schema
> > namespace itself.
>
> > The change you show doesn't look right. The code is written to avoid using
> "xsd"
> > if it's being used for something else already. A Q prefix will be
> introduced in
> > the case of adding a declaration with a namespace not previously used or in
> the
> > case that "xsd" is used for something else...
>
> > The important question here is why is the guarded failing to find an existing
> > xmlns declaration? I suspect it has to do with namespace awareness in how
> the DOM
> > was constructed...
>
> > Hayden Marchant wrote:
>
> > > Ed,
> > >
> > > Shouldn't the code read:
> > >
> > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xsd"))
> > > {
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:xsd", namespace);
> > > }
> > > return "xsd";
> > >
> > > as opposed to :
> > >
> > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xsd"))
> > > {
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:xsd", namespace);
> > > return "xsd";
> > > }
> > >
> > > i.e. when I debugged the code, I got to this method call. My schema
> > > element does have the relevant attribute set to 'xsd'. So the code does
> > > not need to call setAttributeNS and should return nicely. However, it
> > > carries on a resets a duplicate namespace for XSD.
> > >
> > > In my opinion, it's a simple bug - I made a local change in my copy of the
> > > eclipse src and it sort of solved it. Am I talking sense?
> > >
> > > I am still not clear of the case that the code is ever supposed to get to
> > > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > > more correct to check ALL of the attributes, and if there exists an
> > > attribute that has a valid value for
> > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> > > of that attribute should be returned as the namespace for that method.
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > In XSDConcreteComponentImpl there is this method:
> > >
> > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > {
> > > > XSDSchema xsdSchema = getSchema();
> > > > if (namespace == null)
> > > > {
> > > > namespace = "";
> > > > }
> > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > {
> > > > Element schemaElement = xsdSchema.getElement();
> > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > {
> > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xsd"))
> > >
> > > > {
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:xsd", namespace);
> > > > return "xsd";
> > > > }
> > > > }
> > >
> > > > String qualifier = "Q";
> > > > int count = 1;
> > > > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:" + qualifier + count))
> > > > {
> > > > ++count;
> > > > }
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:"
> +
> > > > qualifier + count, namespace);
> > > > return qualifier + count;
> > > > }
> > > > else
> > > > {
> > > > return null;
> > > > }
> > > > }
> > >
> > > > It's called from one place that looks like this:
> > >
> > > > String qualifier = XSDConstants.lookupQualifier(element,
> namespace);
> > > > if (qualifier == null)
> > > > {
> > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > }
> > >
> > > > So it should create a new xmlns declaration only if there isn't already
> one.
> > >
> > > > I'm not sure how the duplication can happen given this algorithm...
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I am merging the contents of schemas by iterating over the elements of
> the
> > > > > referred schemas of a certain base schema and adding all the contents
> of
> > > > > them into the base schema. Here is a snippet of my code:
> > > > >
> > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > >
> > > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > > iterator.hasNext();) {
> > > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > > >
> > > > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > }
> > > > >
> > > > > This code works nicely. However, sometimes when I run this code, I get
> a
> > > > > weird phenomenom. The root of the schema becomes:
> > > > >
> > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > >
> > > > > I have no idea where this Q1 comes from, but lots of the xsd elements
> from
> > > > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > >
> > > > > Also, when validating this schema, all elements that are of type
> > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > > > seems to have been some duplication of XMLSchema namespaces when
> objects
> > > > > were moved over.
> > > > >
> > > > > Any idea what I may be doing wrong?
> > > > >
> > > > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #30635 is a reply to message #30461] |
Tue, 30 September 2003 04:42 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
The hold in editing support is not a problem for me - I delete lots of
items from included schemas, and then I move all of the elements from the
included schemas into the main including schema and then I save the new
schema. So I don't need to tell the including schema that an included
schema changed since ?I then dump everything all into the including schema
after that anyway.
The idea is that there's a very large XSD standard which is spread over a
few documents. The XSD Standard is too big to be validated against, so
several legal subsets of this standard need to be generated acording to
certain criteria - this is what I'm doing. I chop off the irrelevant parts
of the schema whilst making sure I don't leave any bad bits hanging. Then
I merge all the smaller schemas into 1 large schema. There is not a
problem with this - it works great. The problem is, is that after doing
this action, when I open another extremely trivial schema that Eclipse was
very happy with before, I now get errors. In a different JVM the small
schema is fine, it's just that after doing the removing of elements and
merging that the Eclipse parser seems to 'break'.
Any ideas how I can proceed, or maybe that's enough suspicions to look
into a certain part. Again, it looks like the xsd namespace -
http://www.w3.org/2001/XMLSchema seems to have been duplicated or lost or
something, as can be seen from the diagnostic that I got below with the
perfectly legal xsd.
Thanks,
Ed Merks wrote:
> Hayden,
> There is a significant hole in the editing support that editing changes don't
> propagate across schemas. So if you delete something from an included
schema, the
> including schema won't know about that. You should restrict editing to the
"root"
> schema, i.e., the one that includes and imports the others; or you need to
rebuild
> model for the schemas affected by the change. There should probably be a
method on
> XSDSchema that forces such a recomputation to happen...
> Hayden Marchant wrote:
> > I'm still getting another related problem - in fact, I have cornered it
> > down quite a specific scenario:
> >
> > 1. Load a simple XSDSchema, for example:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > xmlns="http://ACORD.org/Standards/Life/2"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xsd:complexType name="INQUIRY_LEVEL_CODES">
> > <xsd:simpleContent>
> > <xsd:extension base="xsd:string">
> > <xsd:attribute name="tc" use="required">
> > <xsd:simpleType>
> > <xsd:restriction base="xsd:nonNegativeInteger">
> > <xsd:enumeration value="1"/>
> > <xsd:enumeration value="2"/>
> > <xsd:enumeration value="3"/>
> > </xsd:restriction>
> > </xsd:simpleType>
> > </xsd:attribute>
> > </xsd:extension>
> > </xsd:simpleContent>
> > </xsd:complexType>
> > <xsd:element name="VendorName">
> > <xsd:complexType>
> > <xsd:simpleContent>
> > <xsd:extension base="xsd:string">
> > <xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
> > </xsd:extension>
> > </xsd:simpleContent>
> > </xsd:complexType>
> > </xsd:element>
> > </xsd:schema>
> >
> > The schema is valid 100% and has no diagnostics.
> >
> > 2. Load an XSDSchema2 that has nested includes.
> > 3. Remove elements from both this schemas and some of the includes (if I
> > only remove from this schema and NOT from includes, bug does not happen).
> > 4. dump the pruned main XSDSchema2 to an OutputStream.
> > 5. Repeat step 1 - this step the same schema has the following diagnostic:
> >
> > Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
> > unresolved.
> >
> > Basically, Eclipse XSD seems to break after removing items from nested
> > schemas. I cna't isolate this bug to such an extent that I can send a
> > reproducable code but above is that basic scenario. Has anyone come across
> > something like this?
> >
> > Thanks
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > Sorry for the earlier miss send.
> >
> > > As I indicated in my previous note, the method is called from a guard:
> >
> > > protected void niceSetAttributeURIValue(Element element, String
attribute,
> > > String uriList)
> > > {
> > > ....
> > > String qualifier = XSDConstants.lookupQualifier(element,
namespace);
> > > if (qualifier == null)
> > > {
> > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > }
> >
> > > So if there is an xmlns declaration already for the namespace, it should
be
> > used.
> > > I.e., all the attributes are checked as you suggest.
> >
> > > I have a strong suspicion that the DOM elements you are manipulating were
> > created
> > > without namespace awareness. Could that be the case?
> >
> > > The xsd prefix is not so presumptuous considering the Primer example:
> >
> > >
http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> >
> > > This special case is only there to avoid the use "Q" for the special
schema
> > > namespace itself.
> >
> > > The change you show doesn't look right. The code is written to avoid
using
> > "xsd"
> > > if it's being used for something else already. A Q prefix will be
> > introduced in
> > > the case of adding a declaration with a namespace not previously used or
in
> > the
> > > case that "xsd" is used for something else...
> >
> > > The important question here is why is the guarded failing to find an
existing
> > > xmlns declaration? I suspect it has to do with namespace awareness in
how
> > the DOM
> > > was constructed...
> >
> > > Hayden Marchant wrote:
> >
> > > > Ed,
> > > >
> > > > Shouldn't the code read:
> > > >
> > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xsd"))
> > > > {
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:xsd", namespace);
> > > > }
> > > > return "xsd";
> > > >
> > > > as opposed to :
> > > >
> > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xsd"))
> > > > {
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:xsd", namespace);
> > > > return "xsd";
> > > > }
> > > >
> > > > i.e. when I debugged the code, I got to this method call. My schema
> > > > element does have the relevant attribute set to 'xsd'. So the code does
> > > > not need to call setAttributeNS and should return nicely. However, it
> > > > carries on a resets a duplicate namespace for XSD.
> > > >
> > > > In my opinion, it's a simple bug - I made a local change in my copy of
the
> > > > eclipse src and it sort of solved it. Am I talking sense?
> > > >
> > > > I am still not clear of the case that the code is ever supposed to get
to
> > > > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > > > more correct to check ALL of the attributes, and if there exists an
> > > > attribute that has a valid value for
> > > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the
name
> > > > of that attribute should be returned as the namespace for that method.
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > In XSDConcreteComponentImpl there is this method:
> > > >
> > > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > > {
> > > > > XSDSchema xsdSchema = getSchema();
> > > > > if (namespace == null)
> > > > > {
> > > > > namespace = "";
> > > > > }
> > > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > > {
> > > > > Element schemaElement = xsdSchema.getElement();
> > > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > > {
> > > > > if
(!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xsd"))
> > > >
> > > > > {
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:xsd", namespace);
> > > > > return "xsd";
> > > > > }
> > > > > }
> > > >
> > > > > String qualifier = "Q";
> > > > > int count = 1;
> > > > > while
(schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:" + qualifier + count))
> > > > > {
> > > > > ++count;
> > > > > }
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:"
> > +
> > > > > qualifier + count, namespace);
> > > > > return qualifier + count;
> > > > > }
> > > > > else
> > > > > {
> > > > > return null;
> > > > > }
> > > > > }
> > > >
> > > > > It's called from one place that looks like this:
> > > >
> > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > namespace);
> > > > > if (qualifier == null)
> > > > > {
> > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > }
> > > >
> > > > > So it should create a new xmlns declaration only if there isn't
already
> > one.
> > > >
> > > > > I'm not sure how the duplication can happen given this algorithm...
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > I am merging the contents of schemas by iterating over the
elements of
> > the
> > > > > > referred schemas of a certain base schema and adding all the
contents
> > of
> > > > > > them into the base schema. Here is a snippet of my code:
> > > > > >
> > > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > > >
> > > > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > > > iterator.hasNext();) {
> > > > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > > > >
> > > > > >
primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > > }
> > > > > >
> > > > > > This code works nicely. However, sometimes when I run this code, I
get
> > a
> > > > > > weird phenomenom. The root of the schema becomes:
> > > > > >
> > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > >
> > > > > > I have no idea where this Q1 comes from, but lots of the xsd
elements
> > from
> > > > > > the XMLSchema schema are prefixed with Q1 instead of xsd.
Sometimes the
> > > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > > >
> > > > > > Also, when validating this schema, all elements that are of type
> > > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
There
> > > > > > seems to have been some duplication of XMLSchema namespaces when
> > objects
> > > > > > were moved over.
> > > > > >
> > > > > > Any idea what I may be doing wrong?
> > > > > >
> > > > > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #30705 is a reply to message #30635] |
Tue, 30 September 2003 12:00 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
It sounds like perhaps maybe the schema for schemas itself got edited
accidentally. It lives in global resource set with static lifetime. It's the
schema returned by XSDSchema.getSchemaForSchema. You could try adding an
org.eclipse.emf.ecore.util.EContentAdapter to it and putting a print statement in
the notifyChanged method to see if maybe some of your code is accidentally editing
it.
Hayden Marchant wrote:
> The hold in editing support is not a problem for me - I delete lots of
> items from included schemas, and then I move all of the elements from the
> included schemas into the main including schema and then I save the new
> schema. So I don't need to tell the including schema that an included
> schema changed since ?I then dump everything all into the including schema
> after that anyway.
>
> The idea is that there's a very large XSD standard which is spread over a
> few documents. The XSD Standard is too big to be validated against, so
> several legal subsets of this standard need to be generated acording to
> certain criteria - this is what I'm doing. I chop off the irrelevant parts
> of the schema whilst making sure I don't leave any bad bits hanging. Then
> I merge all the smaller schemas into 1 large schema. There is not a
> problem with this - it works great. The problem is, is that after doing
> this action, when I open another extremely trivial schema that Eclipse was
> very happy with before, I now get errors. In a different JVM the small
> schema is fine, it's just that after doing the removing of elements and
> merging that the Eclipse parser seems to 'break'.
>
> Any ideas how I can proceed, or maybe that's enough suspicions to look
> into a certain part. Again, it looks like the xsd namespace -
> http://www.w3.org/2001/XMLSchema seems to have been duplicated or lost or
> something, as can be seen from the diagnostic that I got below with the
> perfectly legal xsd.
>
> Thanks,
>
> Ed Merks wrote:
>
> > Hayden,
>
> > There is a significant hole in the editing support that editing changes don't
> > propagate across schemas. So if you delete something from an included
> schema, the
> > including schema won't know about that. You should restrict editing to the
> "root"
> > schema, i.e., the one that includes and imports the others; or you need to
> rebuild
> > model for the schemas affected by the change. There should probably be a
> method on
> > XSDSchema that forces such a recomputation to happen...
>
> > Hayden Marchant wrote:
>
> > > I'm still getting another related problem - in fact, I have cornered it
> > > down quite a specific scenario:
> > >
> > > 1. Load a simple XSDSchema, for example:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > xmlns="http://ACORD.org/Standards/Life/2"
> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xsd:complexType name="INQUIRY_LEVEL_CODES">
> > > <xsd:simpleContent>
> > > <xsd:extension base="xsd:string">
> > > <xsd:attribute name="tc" use="required">
> > > <xsd:simpleType>
> > > <xsd:restriction base="xsd:nonNegativeInteger">
> > > <xsd:enumeration value="1"/>
> > > <xsd:enumeration value="2"/>
> > > <xsd:enumeration value="3"/>
> > > </xsd:restriction>
> > > </xsd:simpleType>
> > > </xsd:attribute>
> > > </xsd:extension>
> > > </xsd:simpleContent>
> > > </xsd:complexType>
> > > <xsd:element name="VendorName">
> > > <xsd:complexType>
> > > <xsd:simpleContent>
> > > <xsd:extension base="xsd:string">
> > > <xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
> > > </xsd:extension>
> > > </xsd:simpleContent>
> > > </xsd:complexType>
> > > </xsd:element>
> > > </xsd:schema>
> > >
> > > The schema is valid 100% and has no diagnostics.
> > >
> > > 2. Load an XSDSchema2 that has nested includes.
> > > 3. Remove elements from both this schemas and some of the includes (if I
> > > only remove from this schema and NOT from includes, bug does not happen).
> > > 4. dump the pruned main XSDSchema2 to an OutputStream.
> > > 5. Repeat step 1 - this step the same schema has the following diagnostic:
> > >
> > > Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
> > > unresolved.
> > >
> > > Basically, Eclipse XSD seems to break after removing items from nested
> > > schemas. I cna't isolate this bug to such an extent that I can send a
> > > reproducable code but above is that basic scenario. Has anyone come across
> > > something like this?
> > >
> > > Thanks
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > Sorry for the earlier miss send.
> > >
> > > > As I indicated in my previous note, the method is called from a guard:
> > >
> > > > protected void niceSetAttributeURIValue(Element element, String
> attribute,
> > > > String uriList)
> > > > {
> > > > ....
> > > > String qualifier = XSDConstants.lookupQualifier(element,
> namespace);
> > > > if (qualifier == null)
> > > > {
> > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > }
> > >
> > > > So if there is an xmlns declaration already for the namespace, it should
> be
> > > used.
> > > > I.e., all the attributes are checked as you suggest.
> > >
> > > > I have a strong suspicion that the DOM elements you are manipulating were
> > > created
> > > > without namespace awareness. Could that be the case?
> > >
> > > > The xsd prefix is not so presumptuous considering the Primer example:
> > >
> > > >
> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> > >
> > > > This special case is only there to avoid the use "Q" for the special
> schema
> > > > namespace itself.
> > >
> > > > The change you show doesn't look right. The code is written to avoid
> using
> > > "xsd"
> > > > if it's being used for something else already. A Q prefix will be
> > > introduced in
> > > > the case of adding a declaration with a namespace not previously used or
> in
> > > the
> > > > case that "xsd" is used for something else...
> > >
> > > > The important question here is why is the guarded failing to find an
> existing
> > > > xmlns declaration? I suspect it has to do with namespace awareness in
> how
> > > the DOM
> > > > was constructed...
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Shouldn't the code read:
> > > > >
> > > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xsd"))
> > > > > {
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:xsd", namespace);
> > > > > }
> > > > > return "xsd";
> > > > >
> > > > > as opposed to :
> > > > >
> > > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xsd"))
> > > > > {
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:xsd", namespace);
> > > > > return "xsd";
> > > > > }
> > > > >
> > > > > i.e. when I debugged the code, I got to this method call. My schema
> > > > > element does have the relevant attribute set to 'xsd'. So the code does
> > > > > not need to call setAttributeNS and should return nicely. However, it
> > > > > carries on a resets a duplicate namespace for XSD.
> > > > >
> > > > > In my opinion, it's a simple bug - I made a local change in my copy of
> the
> > > > > eclipse src and it sort of solved it. Am I talking sense?
> > > > >
> > > > > I am still not clear of the case that the code is ever supposed to get
> to
> > > > > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > > > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > > > > more correct to check ALL of the attributes, and if there exists an
> > > > > attribute that has a valid value for
> > > > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the
> name
> > > > > of that attribute should be returned as the namespace for that method.
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > Hayden,
> > > > >
> > > > > > In XSDConcreteComponentImpl there is this method:
> > > > >
> > > > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > > > {
> > > > > > XSDSchema xsdSchema = getSchema();
> > > > > > if (namespace == null)
> > > > > > {
> > > > > > namespace = "";
> > > > > > }
> > > > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > > > {
> > > > > > Element schemaElement = xsdSchema.getElement();
> > > > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > > > {
> > > > > > if
> (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xsd"))
> > > > >
> > > > > > {
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:xsd", namespace);
> > > > > > return "xsd";
> > > > > > }
> > > > > > }
> > > > >
> > > > > > String qualifier = "Q";
> > > > > > int count = 1;
> > > > > > while
> (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:" + qualifier + count))
> > > > > > {
> > > > > > ++count;
> > > > > > }
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:"
> > > +
> > > > > > qualifier + count, namespace);
> > > > > > return qualifier + count;
> > > > > > }
> > > > > > else
> > > > > > {
> > > > > > return null;
> > > > > > }
> > > > > > }
> > > > >
> > > > > > It's called from one place that looks like this:
> > > > >
> > > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > > namespace);
> > > > > > if (qualifier == null)
> > > > > > {
> > > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > > }
> > > > >
> > > > > > So it should create a new xmlns declaration only if there isn't
> already
> > > one.
> > > > >
> > > > > > I'm not sure how the duplication can happen given this algorithm...
> > > > >
> > > > > > Hayden Marchant wrote:
> > > > >
> > > > > > > I am merging the contents of schemas by iterating over the
> elements of
> > > the
> > > > > > > referred schemas of a certain base schema and adding all the
> contents
> > > of
> > > > > > > them into the base schema. Here is a snippet of my code:
> > > > > > >
> > > > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > > > >
> > > > > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > > > > iterator.hasNext();) {
> > > > > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > > > > >
> > > > > > >
> primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > > > }
> > > > > > >
> > > > > > > This code works nicely. However, sometimes when I run this code, I
> get
> > > a
> > > > > > > weird phenomenom. The root of the schema becomes:
> > > > > > >
> > > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > >
> > > > > > > I have no idea where this Q1 comes from, but lots of the xsd
> elements
> > > from
> > > > > > > the XMLSchema schema are prefixed with Q1 instead of xsd.
> Sometimes the
> > > > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > > > >
> > > > > > > Also, when validating this schema, all elements that are of type
> > > > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
> There
> > > > > > > seems to have been some duplication of XMLSchema namespaces when
> > > objects
> > > > > > > were moved over.
> > > > > > >
> > > > > > > Any idea what I may be doing wrong?
> > > > > > >
> > > > > > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #30778 is a reply to message #30705] |
Tue, 30 September 2003 12:54 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Ed,
You pointed me in exactly the right direction - you were correct in your
analysis - I was removing some quite vital parts of the static schema.
That probably solves the Q1 namespace problem aswell.
Thanks so much for your help.
I'm glad it was a bug in my code and not in Eclipse :)
Ed Merks wrote:
> Hayden,
> It sounds like perhaps maybe the schema for schemas itself got edited
> accidentally. It lives in global resource set with static lifetime. It's
the
> schema returned by XSDSchema.getSchemaForSchema. You could try adding an
> org.eclipse.emf.ecore.util.EContentAdapter to it and putting a print
statement in
> the notifyChanged method to see if maybe some of your code is accidentally
editing
> it.
> Hayden Marchant wrote:
> > The hold in editing support is not a problem for me - I delete lots of
> > items from included schemas, and then I move all of the elements from the
> > included schemas into the main including schema and then I save the new
> > schema. So I don't need to tell the including schema that an included
> > schema changed since ?I then dump everything all into the including schema
> > after that anyway.
> >
> > The idea is that there's a very large XSD standard which is spread over a
> > few documents. The XSD Standard is too big to be validated against, so
> > several legal subsets of this standard need to be generated acording to
> > certain criteria - this is what I'm doing. I chop off the irrelevant parts
> > of the schema whilst making sure I don't leave any bad bits hanging. Then
> > I merge all the smaller schemas into 1 large schema. There is not a
> > problem with this - it works great. The problem is, is that after doing
> > this action, when I open another extremely trivial schema that Eclipse was
> > very happy with before, I now get errors. In a different JVM the small
> > schema is fine, it's just that after doing the removing of elements and
> > merging that the Eclipse parser seems to 'break'.
> >
> > Any ideas how I can proceed, or maybe that's enough suspicions to look
> > into a certain part. Again, it looks like the xsd namespace -
> > http://www.w3.org/2001/XMLSchema seems to have been duplicated or lost or
> > something, as can be seen from the diagnostic that I got below with the
> > perfectly legal xsd.
> >
> > Thanks,
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > There is a significant hole in the editing support that editing changes
don't
> > > propagate across schemas. So if you delete something from an included
> > schema, the
> > > including schema won't know about that. You should restrict editing to
the
> > "root"
> > > schema, i.e., the one that includes and imports the others; or you need
to
> > rebuild
> > > model for the schemas affected by the change. There should probably be a
> > method on
> > > XSDSchema that forces such a recomputation to happen...
> >
> > > Hayden Marchant wrote:
> >
> > > > I'm still getting another related problem - in fact, I have cornered it
> > > > down quite a specific scenario:
> > > >
> > > > 1. Load a simple XSDSchema, for example:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xsd:complexType name="INQUIRY_LEVEL_CODES">
> > > > <xsd:simpleContent>
> > > > <xsd:extension base="xsd:string">
> > > > <xsd:attribute name="tc" use="required">
> > > > <xsd:simpleType>
> > > > <xsd:restriction base="xsd:nonNegativeInteger">
> > > > <xsd:enumeration value="1"/>
> > > > <xsd:enumeration value="2"/>
> > > > <xsd:enumeration value="3"/>
> > > > </xsd:restriction>
> > > > </xsd:simpleType>
> > > > </xsd:attribute>
> > > > </xsd:extension>
> > > > </xsd:simpleContent>
> > > > </xsd:complexType>
> > > > <xsd:element name="VendorName">
> > > > <xsd:complexType>
> > > > <xsd:simpleContent>
> > > > <xsd:extension base="xsd:string">
> > > > <xsd:attribute name="VendorCode" type="xsd:string"
use="required"/>
> > > > </xsd:extension>
> > > > </xsd:simpleContent>
> > > > </xsd:complexType>
> > > > </xsd:element>
> > > > </xsd:schema>
> > > >
> > > > The schema is valid 100% and has no diagnostics.
> > > >
> > > > 2. Load an XSDSchema2 that has nested includes.
> > > > 3. Remove elements from both this schemas and some of the includes (if
I
> > > > only remove from this schema and NOT from includes, bug does not
happen).
> > > > 4. dump the pruned main XSDSchema2 to an OutputStream.
> > > > 5. Repeat step 1 - this step the same schema has the following
diagnostic:
> > > >
> > > > Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string'
is
> > > > unresolved.
> > > >
> > > > Basically, Eclipse XSD seems to break after removing items from nested
> > > > schemas. I cna't isolate this bug to such an extent that I can send a
> > > > reproducable code but above is that basic scenario. Has anyone come
across
> > > > something like this?
> > > >
> > > > Thanks
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > Sorry for the earlier miss send.
> > > >
> > > > > As I indicated in my previous note, the method is called from a
guard:
> > > >
> > > > > protected void niceSetAttributeURIValue(Element element, String
> > attribute,
> > > > > String uriList)
> > > > > {
> > > > > ....
> > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > namespace);
> > > > > if (qualifier == null)
> > > > > {
> > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > }
> > > >
> > > > > So if there is an xmlns declaration already for the namespace, it
should
> > be
> > > > used.
> > > > > I.e., all the attributes are checked as you suggest.
> > > >
> > > > > I have a strong suspicion that the DOM elements you are manipulating
were
> > > > created
> > > > > without namespace awareness. Could that be the case?
> > > >
> > > > > The xsd prefix is not so presumptuous considering the Primer example:
> > > >
> > > > >
> > http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> > > >
> > > > > This special case is only there to avoid the use "Q" for the special
> > schema
> > > > > namespace itself.
> > > >
> > > > > The change you show doesn't look right. The code is written to avoid
> > using
> > > > "xsd"
> > > > > if it's being used for something else already. A Q prefix will be
> > > > introduced in
> > > > > the case of adding a declaration with a namespace not previously
used or
> > in
> > > > the
> > > > > case that "xsd" is used for something else...
> > > >
> > > > > The important question here is why is the guarded failing to find an
> > existing
> > > > > xmlns declaration? I suspect it has to do with namespace awareness
in
> > how
> > > > the DOM
> > > > > was constructed...
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Shouldn't the code read:
> > > > > >
> > > > > > if
(!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xsd"))
> > > > > > {
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:xsd", namespace);
> > > > > > }
> > > > > > return "xsd";
> > > > > >
> > > > > > as opposed to :
> > > > > >
> > > > > > if
(!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xsd"))
> > > > > > {
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:xsd", namespace);
> > > > > > return "xsd";
> > > > > > }
> > > > > >
> > > > > > i.e. when I debugged the code, I got to this method call. My schema
> > > > > > element does have the relevant attribute set to 'xsd'. So the code
does
> > > > > > not need to call setAttributeNS and should return nicely. However,
it
> > > > > > carries on a resets a duplicate namespace for XSD.
> > > > > >
> > > > > > In my opinion, it's a simple bug - I made a local change in my
copy of
> > the
> > > > > > eclipse src and it sort of solved it. Am I talking sense?
> > > > > >
> > > > > > I am still not clear of the case that the code is ever supposed to
get
> > to
> > > > > > make a "Q" XSD namespace. Also isn't it a bit presumptious that
the XSD
> > > > > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't
it be
> > > > > > more correct to check ALL of the attributes, and if there exists an
> > > > > > attribute that has a valid value for
> > > > > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and
the
> > name
> > > > > > of that attribute should be returned as the namespace for that
method.
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > Hayden,
> > > > > >
> > > > > > > In XSDConcreteComponentImpl there is this method:
> > > > > >
> > > > > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > > > > {
> > > > > > > XSDSchema xsdSchema = getSchema();
> > > > > > > if (namespace == null)
> > > > > > > {
> > > > > > > namespace = "";
> > > > > > > }
> > > > > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > > > > {
> > > > > > > Element schemaElement = xsdSchema.getElement();
> > > > > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > > > > {
> > > > > > > if
> > (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xsd"))
> > > > > >
> > > > > > > {
> > > > > > >
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > > "xmlns:xsd", namespace);
> > > > > > > return "xsd";
> > > > > > > }
> > > > > > > }
> > > > > >
> > > > > > > String qualifier = "Q";
> > > > > > > int count = 1;
> > > > > > > while
> > (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > > "xmlns:" + qualifier + count))
> > > > > > > {
> > > > > > > ++count;
> > > > > > > }
> > > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:"
> > > > +
> > > > > > > qualifier + count, namespace);
> > > > > > > return qualifier + count;
> > > > > > > }
> > > > > > > else
> > > > > > > {
> > > > > > > return null;
> > > > > > > }
> > > > > > > }
> > > > > >
> > > > > > > It's called from one place that looks like this:
> > > > > >
> > > > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > > > namespace);
> > > > > > > if (qualifier == null)
> > > > > > > {
> > > > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > > > }
> > > > > >
> > > > > > > So it should create a new xmlns declaration only if there isn't
> > already
> > > > one.
> > > > > >
> > > > > > > I'm not sure how the duplication can happen given this
algorithm...
> > > > > >
> > > > > > > Hayden Marchant wrote:
> > > > > >
> > > > > > > > I am merging the contents of schemas by iterating over the
> > elements of
> > > > the
> > > > > > > > referred schemas of a certain base schema and adding all the
> > contents
> > > > of
> > > > > > > > them into the base schema. Here is a snippet of my code:
> > > > > > > >
> > > > > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > > > > >
> > > > > > > > for (Iterator iterator =
fReferencedXsdSchemas.iterator();
> > > > > > > > iterator.hasNext();) {
> > > > > > > > XSDSchema referredSchema = (XSDSchema)
iterator.next();
> > > > > > > >
> > > > > > > >
> > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > > > > }
> > > > > > > >
> > > > > > > > This code works nicely. However, sometimes when I run this
code, I
> > get
> > > > a
> > > > > > > > weird phenomenom. The root of the schema becomes:
> > > > > > > >
> > > > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > >
> > > > > > > > I have no idea where this Q1 comes from, but lots of the xsd
> > elements
> > > > from
> > > > > > > > the XMLSchema schema are prefixed with Q1 instead of xsd.
> > Sometimes the
> > > > > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > > > > >
> > > > > > > > Also, when validating this schema, all elements that are of
type
> > > > > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
> > There
> > > > > > > > seems to have been some duplication of XMLSchema namespaces
when
> > > > objects
> > > > > > > > were moved over.
> > > > > > > >
> > > > > > > > Any idea what I may be doing wrong?
> > > > > > > >
> > > > > > > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #577260 is a reply to message #28174] |
Thu, 04 September 2003 18:32 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
--------------3A07646349EF55C6534EDB66
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
In XSDConcreteComponentImpl there is this method:
protected String niceCreateNamespaceAttribute(String namespace)
{
XSDSchema xsdSchema = getSchema();
if (namespace == null)
{
namespace = "";
}
if (xsdSchema != null && xsdSchema.getElement() != null)
{
Element schemaElement = xsdSchema.getElement();
if (XSDConstants.isSchemaForSchemaNamespace(namespace))
{
if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000, "xsd"))
{
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);
return "xsd";
}
}
String qualifier = "Q";
int count = 1;
while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" + qualifier + count))
{
++count;
}
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
qualifier + count, namespace);
return qualifier + count;
}
else
{
return null;
}
}
It's called from one place that looks like this:
String qualifier = XSDConstants.lookupQualifier(element, namespace);
if (qualifier == null)
{
qualifier = niceCreateNamespaceAttribute(namespace);
}
So it should create a new xmlns declaration only if there isn't already one.
I'm not sure how the duplication can happen given this algorithm...
Hayden Marchant wrote:
> I am merging the contents of schemas by iterating over the elements of the
> referred schemas of a certain base schema and adding all the contents of
> them into the base schema. Here is a snippet of my code:
>
> XSDSchema primaryXSDSchema = getEclipseXSDSchema();
>
> for (Iterator iterator = fReferencedXsdSchemas.iterator();
> iterator.hasNext();) {
> XSDSchema referredSchema = (XSDSchema) iterator.next();
>
> primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> }
>
> This code works nicely. However, sometimes when I run this code, I get a
> weird phenomenom. The root of the schema becomes:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> xmlns="http://ACORD.org/Standards/Life/2"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
>
> I have no idea where this Q1 comes from, but lots of the xsd elements from
> the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> whole schema is Q1. e.g. <Q1:schema>.....
>
> Also, when validating this schema, all elements that are of type
> <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> seems to have been some duplication of XMLSchema namespaces when objects
> were moved over.
>
> Any idea what I may be doing wrong?
>
> Thanks
--------------3A07646349EF55C6534EDB66
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>In XSDConcreteComponentImpl there is this method:
<p><tt> protected String niceCreateNamespaceAttribute(String namespace)</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (namespace == null)</tt>
<br><tt> {</tt>
<br><tt> namespace = "";</tt>
<br><tt> }</tt>
<br><tt> if (xsdSchema != null && xsdSchema.getElement()
!= null)</tt>
<br><tt> {</tt>
<br><tt> Element schemaElement = xsdSchema.getElement();</tt>
<br><tt> if (XSDConstants.isSchemaForSchemaNamespace(namespace))</tt>
<br><tt> {</tt>
<br><tt> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))</tt>
<br><tt> {</tt>
<br><tt> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);</tt>
<br><tt> return "xsd";</tt>
<br><tt> }</tt>
<br><tt> }</tt><tt></tt>
<p><tt> String qualifier = "Q";</tt>
<br><tt> int count = 1;</tt>
<br><tt> while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" + qualifier + count))</tt>
<br><tt> {</tt>
<br><tt> ++count;</tt>
<br><tt> }</tt>
<br><tt> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" + qualifier + count, namespace);</tt>
<br><tt> return qualifier + count;</tt>
<br><tt> }</tt>
<br><tt> else</tt>
<br><tt> {</tt>
<br><tt> return null;</tt>
<br><tt> }</tt>
<br><tt> }</tt>
<p>It's called from one place that looks like this:
<p> String qualifier = XSDConstants.lookupQualifier(element,
namespace);
<br> if (qualifier == null)
<br> {
<br> qualifier =
niceCreateNamespaceAttribute(namespace);
<br> }
<p>So it should create a new xmlns declaration only if there isn't already
one.
<p>I'm not sure how the duplication can happen given this algorithm...
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>I am merging the contents of schemas by iterating
over the elements of the
<br>referred schemas of a certain base schema and adding all the contents
of
<br>them into the base schema. Here is a snippet of my code:
<p> XSDSchema primaryXSDSchema
= getEclipseXSDSchema();
<p> for (Iterator iterator =
fReferencedXsdSchemas.iterator();
<br>iterator.hasNext();) {
<br>
XSDSchema referredSchema = (XSDSchema) iterator.next();
<p> primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
<br> }
<p>This code works nicely. However, sometimes when I run this code, I get
a
<br>weird phenomenom. The root of the schema becomes:
<p><?xml version="1.0" encoding="UTF-8"?>
<br><xsd:schema targetNamespace="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>xmlns:Q1="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>xmlns="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>xmlns:xsd="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>elementFormDefault="unqualified" attributeFormDefault="unqualified">
<p>I have no idea where this Q1 comes from, but lots of the xsd elements
from
<br>the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes
the
<br>whole schema is Q1. e.g. <Q1:schema>.....
<p>Also, when validating this schema, all elements that are of type
<br><Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
There
<br>seems to have been some duplication of XMLSchema namespaces when objects
<br>were moved over.
<p>Any idea what I may be doing wrong?
<p>Thanks</blockquote>
</html>
--------------3A07646349EF55C6534EDB66--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #577314 is a reply to message #28216] |
Sat, 06 September 2003 19:36 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Ed,
Shouldn't the code read:
if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))
{
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);
}
return "xsd";
as opposed to :
if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))
{
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:xsd", namespace);
return "xsd";
}
i.e. when I debugged the code, I got to this method call. My schema
element does have the relevant attribute set to 'xsd'. So the code does
not need to call setAttributeNS and should return nicely. However, it
carries on a resets a duplicate namespace for XSD.
In my opinion, it's a simple bug - I made a local change in my copy of the
eclipse src and it sort of solved it. Am I talking sense?
I am still not clear of the case that the code is ever supposed to get to
make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
more correct to check ALL of the attributes, and if there exists an
attribute that has a valid value for
XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
of that attribute should be returned as the namespace for that method.
Ed Merks wrote:
> Hayden,
> In XSDConcreteComponentImpl there is this method:
> protected String niceCreateNamespaceAttribute(String namespace)
> {
> XSDSchema xsdSchema = getSchema();
> if (namespace == null)
> {
> namespace = "";
> }
> if (xsdSchema != null && xsdSchema.getElement() != null)
> {
> Element schemaElement = xsdSchema.getElement();
> if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> {
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
"xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> return "xsd";
> }
> }
> String qualifier = "Q";
> int count = 1;
> while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:" + qualifier + count))
> {
> ++count;
> }
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
> qualifier + count, namespace);
> return qualifier + count;
> }
> else
> {
> return null;
> }
> }
> It's called from one place that looks like this:
> String qualifier = XSDConstants.lookupQualifier(element, namespace);
> if (qualifier == null)
> {
> qualifier = niceCreateNamespaceAttribute(namespace);
> }
> So it should create a new xmlns declaration only if there isn't already one.
> I'm not sure how the duplication can happen given this algorithm...
> Hayden Marchant wrote:
> > I am merging the contents of schemas by iterating over the elements of the
> > referred schemas of a certain base schema and adding all the contents of
> > them into the base schema. Here is a snippet of my code:
> >
> > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> >
> > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > iterator.hasNext();) {
> > XSDSchema referredSchema = (XSDSchema) iterator.next();
> >
> > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > }
> >
> > This code works nicely. However, sometimes when I run this code, I get a
> > weird phenomenom. The root of the schema becomes:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > xmlns="http://ACORD.org/Standards/Life/2"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> >
> > I have no idea where this Q1 comes from, but lots of the xsd elements from
> > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > whole schema is Q1. e.g. <Q1:schema>.....
> >
> > Also, when validating this schema, all elements that are of type
> > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > seems to have been some duplication of XMLSchema namespaces when objects
> > were moved over.
> >
> > Any idea what I may be doing wrong?
> >
> > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #577341 is a reply to message #28293] |
Sun, 07 September 2003 13:46 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hayden,
As I indicated in my previous note, the method is called from a guard:
Hayden Marchant wrote:
> Ed,
>
> Shouldn't the code read:
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> }
> return "xsd";
>
> as opposed to :
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> return "xsd";
> }
>
> i.e. when I debugged the code, I got to this method call. My schema
> element does have the relevant attribute set to 'xsd'. So the code does
> not need to call setAttributeNS and should return nicely. However, it
> carries on a resets a duplicate namespace for XSD.
>
> In my opinion, it's a simple bug - I made a local change in my copy of the
> eclipse src and it sort of solved it. Am I talking sense?
>
> I am still not clear of the case that the code is ever supposed to get to
> make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> more correct to check ALL of the attributes, and if there exists an
> attribute that has a valid value for
> XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> of that attribute should be returned as the namespace for that method.
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In XSDConcreteComponentImpl there is this method:
>
> > protected String niceCreateNamespaceAttribute(String namespace)
> > {
> > XSDSchema xsdSchema = getSchema();
> > if (namespace == null)
> > {
> > namespace = "";
> > }
> > if (xsdSchema != null && xsdSchema.getElement() != null)
> > {
> > Element schemaElement = xsdSchema.getElement();
> > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > {
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
>
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > return "xsd";
> > }
> > }
>
> > String qualifier = "Q";
> > int count = 1;
> > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:" + qualifier + count))
> > {
> > ++count;
> > }
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
> > qualifier + count, namespace);
> > return qualifier + count;
> > }
> > else
> > {
> > return null;
> > }
> > }
>
> > It's called from one place that looks like this:
>
> > String qualifier = XSDConstants.lookupQualifier(element, namespace);
> > if (qualifier == null)
> > {
> > qualifier = niceCreateNamespaceAttribute(namespace);
> > }
>
> > So it should create a new xmlns declaration only if there isn't already one.
>
> > I'm not sure how the duplication can happen given this algorithm...
>
> > Hayden Marchant wrote:
>
> > > I am merging the contents of schemas by iterating over the elements of the
> > > referred schemas of a certain base schema and adding all the contents of
> > > them into the base schema. Here is a snippet of my code:
> > >
> > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > >
> > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > iterator.hasNext();) {
> > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > >
> > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > }
> > >
> > > This code works nicely. However, sometimes when I run this code, I get a
> > > weird phenomenom. The root of the schema becomes:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > xmlns="http://ACORD.org/Standards/Life/2"
> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > I have no idea where this Q1 comes from, but lots of the xsd elements from
> > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > whole schema is Q1. e.g. <Q1:schema>.....
> > >
> > > Also, when validating this schema, all elements that are of type
> > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > seems to have been some duplication of XMLSchema namespaces when objects
> > > were moved over.
> > >
> > > Any idea what I may be doing wrong?
> > >
> > > Thanks
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #577366 is a reply to message #28293] |
Sun, 07 September 2003 14:03 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
--------------D85D31BE0E6A8FCC58FEE674
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
Sorry for the earlier miss send.
As I indicated in my previous note, the method is called from a guard:
protected void niceSetAttributeURIValue(Element element, String attribute,
String uriList)
{
....
String qualifier = XSDConstants.lookupQualifier(element, namespace);
if (qualifier == null)
{
qualifier = niceCreateNamespaceAttribute(namespace);
}
So if there is an xmlns declaration already for the namespace, it should be used.
I.e., all the attributes are checked as you suggest.
I have a strong suspicion that the DOM elements you are manipulating were created
without namespace awareness. Could that be the case?
The xsd prefix is not so presumptuous considering the Primer example:
http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
This special case is only there to avoid the use "Q" for the special schema
namespace itself.
The change you show doesn't look right. The code is written to avoid using "xsd"
if it's being used for something else already. A Q prefix will be introduced in
the case of adding a declaration with a namespace not previously used or in the
case that "xsd" is used for something else...
The important question here is why is the guarded failing to find an existing
xmlns declaration? I suspect it has to do with namespace awareness in how the DOM
was constructed...
Hayden Marchant wrote:
> Ed,
>
> Shouldn't the code read:
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> }
> return "xsd";
>
> as opposed to :
>
> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
> {
> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:xsd", namespace);
> return "xsd";
> }
>
> i.e. when I debugged the code, I got to this method call. My schema
> element does have the relevant attribute set to 'xsd'. So the code does
> not need to call setAttributeNS and should return nicely. However, it
> carries on a resets a duplicate namespace for XSD.
>
> In my opinion, it's a simple bug - I made a local change in my copy of the
> eclipse src and it sort of solved it. Am I talking sense?
>
> I am still not clear of the case that the code is ever supposed to get to
> make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> more correct to check ALL of the attributes, and if there exists an
> attribute that has a valid value for
> XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> of that attribute should be returned as the namespace for that method.
>
> Ed Merks wrote:
>
> > Hayden,
>
> > In XSDConcreteComponentImpl there is this method:
>
> > protected String niceCreateNamespaceAttribute(String namespace)
> > {
> > XSDSchema xsdSchema = getSchema();
> > if (namespace == null)
> > {
> > namespace = "";
> > }
> > if (xsdSchema != null && xsdSchema.getElement() != null)
> > {
> > Element schemaElement = xsdSchema.getElement();
> > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > {
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xsd"))
>
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > return "xsd";
> > }
> > }
>
> > String qualifier = "Q";
> > int count = 1;
> > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:" + qualifier + count))
> > {
> > ++count;
> > }
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:" +
> > qualifier + count, namespace);
> > return qualifier + count;
> > }
> > else
> > {
> > return null;
> > }
> > }
>
> > It's called from one place that looks like this:
>
> > String qualifier = XSDConstants.lookupQualifier(element, namespace);
> > if (qualifier == null)
> > {
> > qualifier = niceCreateNamespaceAttribute(namespace);
> > }
>
> > So it should create a new xmlns declaration only if there isn't already one.
>
> > I'm not sure how the duplication can happen given this algorithm...
>
> > Hayden Marchant wrote:
>
> > > I am merging the contents of schemas by iterating over the elements of the
> > > referred schemas of a certain base schema and adding all the contents of
> > > them into the base schema. Here is a snippet of my code:
> > >
> > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > >
> > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > iterator.hasNext();) {
> > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > >
> > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > }
> > >
> > > This code works nicely. However, sometimes when I run this code, I get a
> > > weird phenomenom. The root of the schema becomes:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > xmlns="http://ACORD.org/Standards/Life/2"
> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > >
> > > I have no idea where this Q1 comes from, but lots of the xsd elements from
> > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > whole schema is Q1. e.g. <Q1:schema>.....
> > >
> > > Also, when validating this schema, all elements that are of type
> > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > seems to have been some duplication of XMLSchema namespaces when objects
> > > were moved over.
> > >
> > > Any idea what I may be doing wrong?
> > >
> > > Thanks
--------------D85D31BE0E6A8FCC58FEE674
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>Sorry for the earlier miss send.
<p>As I indicated in my previous note, the method is called from a guard:
<p> protected void niceSetAttributeURIValue(Element element, String
attribute, String uriList)
<br> {
<br> ....
<br> <font color="#CC0000">String
qualifier = XSDConstants.lookupQualifier(element, namespace);</font>
<br> if (qualifier == null)
<br> {
<br> qualifier =
niceCreateNamespaceAttribute(namespace);
<br> }
<p>So if there is an xmlns declaration already for the namespace, it should
be used. I.e., all the attributes are checked as you suggest.
<p>I have a strong suspicion that the DOM elements you are manipulating
were created without namespace awareness. Could that be the case?
<p>The xsd prefix is not so presumptuous considering the Primer example:
<blockquote><a href=" http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema"> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema</a></blockquote>
This special case is only there to avoid the use "Q" for the special schema
namespace itself.
<p>The change you show doesn't look right. The code is written to
avoid using "xsd" if it's being used for something else already.
A Q prefix will be introduced in the case of adding a declaration with
a namespace not previously used or in the case that "xsd" is used for something
else...
<p>The important question here is why is the guarded failing to find an
existing xmlns declaration? I suspect it has to do with namespace
awareness in how the DOM was constructed...
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>Ed,
<p>Shouldn't the code read:
<p> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xsd"))
<br> {
<br> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xmlns:xsd", namespace);
<br> }
<br> return "xsd";
<p>as opposed to :
<p> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xsd"))
<br> {
<br> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xmlns:xsd", namespace);
<br> return "xsd";
<br> }
<p>i.e. when I debugged the code, I got to this method call. My schema
<br>element does have the relevant attribute set to 'xsd'. So the code
does
<br>not need to call setAttributeNS and should return nicely. However,
it
<br>carries on a resets a duplicate namespace for XSD.
<p>In my opinion, it's a simple bug - I made a local change in my copy
of the
<br>eclipse src and it sort of solved it. Am I talking sense?
<p>I am still not clear of the case that the code is ever supposed to get
to
<br>make a "Q" XSD namespace. Also isn't it a bit presumptious that the
XSD
<br>namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it
be
<br>more correct to check ALL of the attributes, and if there exists an
<br>attribute that has a valid value for
<br>XSDConstants.isSchemaForSchemaNamespace() then that's the one and the
name
<br>of that attribute should be returned as the namespace for that method.
<p>Ed Merks wrote:
<p>> Hayden,
<p>> In XSDConcreteComponentImpl there is this method:
<p>> protected String niceCreateNamespaceAttribute(String namespace)
<br>> {
<br>> XSDSchema xsdSchema = getSchema();
<br>> if (namespace == null)
<br>> {
<br>> namespace = "";
<br>> }
<br>> if (xsdSchema != null && xsdSchema.getElement()
!= null)
<br>> {
<br>> Element schemaElement = xsdSchema.getElement();
<br>> if (XSDConstants.isSchemaForSchemaNamespace(namespace))
<br>> {
<br>> if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>"xsd"))
<p>> {
<br>> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>> "xmlns:xsd", namespace);
<br>> return
"xsd";
<br>> }
<br>> }
<p>> String qualifier = "Q";
<br>> int count = 1;
<br>> while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
<br>> "xmlns:" + qualifier + count))
<br>> {
<br>> ++count;
<br>> }
<br>> schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:" +
<br>> qualifier + count, namespace);
<br>> return qualifier + count;
<br>> }
<br>> else
<br>> {
<br>> return null;
<br>> }
<br>> }
<p>> It's called from one place that looks like this:
<p>> String qualifier =
XSDConstants.lookupQualifier(element, namespace);
<br>> if (qualifier ==
null)
<br>> {
<br>> qualifier
= niceCreateNamespaceAttribute(namespace);
<br>> }
<p>> So it should create a new xmlns declaration only if there isn't already
one.
<p>> I'm not sure how the duplication can happen given this algorithm...
<p>> Hayden Marchant wrote:
<p>> > I am merging the contents of schemas by iterating over the elements
of the
<br>> > referred schemas of a certain base schema and adding all the contents
of
<br>> > them into the base schema. Here is a snippet of my code:
<br>> >
<br>> > XSDSchema primaryXSDSchema
= getEclipseXSDSchema();
<br>> >
<br>> > for (Iterator iterator
= fReferencedXsdSchemas.iterator();
<br>> > iterator.hasNext();) {
<br>> >
XSDSchema referredSchema = (XSDSchema) iterator.next();
<br>> >
<br>> > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
<br>> > }
<br>> >
<br>> > This code works nicely. However, sometimes when I run this code,
I get a
<br>> > weird phenomenom. The root of the schema becomes:
<br>> >
<br>> > <?xml version="1.0" encoding="UTF-8"?>
<br>> > <xsd:schema targetNamespace="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>> > xmlns:Q1="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > xmlns="<a href="http://ACORD.org/Standards/Life/2">http://ACORD.org/Standards/Life/2</a>"
<br>> > xmlns:xsd="<a href="http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchema</a>"
<br>> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
<br>> >
<br>> > I have no idea where this Q1 comes from, but lots of the xsd elements
from
<br>> > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes
the
<br>> > whole schema is Q1. e.g. <Q1:schema>.....
<br>> >
<br>> > Also, when validating this schema, all elements that are of type
<br>> > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
There
<br>> > seems to have been some duplication of XMLSchema namespaces when
objects
<br>> > were moved over.
<br>> >
<br>> > Any idea what I may be doing wrong?
<br>> >
<br>> > Thanks</blockquote>
</html>
--------------D85D31BE0E6A8FCC58FEE674--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #578566 is a reply to message #28368] |
Mon, 29 September 2003 17:18 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
I'm still getting another related problem - in fact, I have cornered it
down quite a specific scenario:
1. Load a simple XSDSchema, for example:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
xmlns="http://ACORD.org/Standards/Life/2"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="unqualified" attributeFormDefault="unqualified">
<xsd:complexType name="INQUIRY_LEVEL_CODES">
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="tc" use="required">
<xsd:simpleType>
<xsd:restriction base="xsd:nonNegativeInteger">
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value="3"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:element name="VendorName">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
The schema is valid 100% and has no diagnostics.
2. Load an XSDSchema2 that has nested includes.
3. Remove elements from both this schemas and some of the includes (if I
only remove from this schema and NOT from includes, bug does not happen).
4. dump the pruned main XSDSchema2 to an OutputStream.
5. Repeat step 1 - this step the same schema has the following diagnostic:
Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
unresolved.
Basically, Eclipse XSD seems to break after removing items from nested
schemas. I cna't isolate this bug to such an extent that I can send a
reproducable code but above is that basic scenario. Has anyone come across
something like this?
Thanks
Ed Merks wrote:
> Hayden,
> Sorry for the earlier miss send.
> As I indicated in my previous note, the method is called from a guard:
> protected void niceSetAttributeURIValue(Element element, String attribute,
> String uriList)
> {
> ....
> String qualifier = XSDConstants.lookupQualifier(element, namespace);
> if (qualifier == null)
> {
> qualifier = niceCreateNamespaceAttribute(namespace);
> }
> So if there is an xmlns declaration already for the namespace, it should be
used.
> I.e., all the attributes are checked as you suggest.
> I have a strong suspicion that the DOM elements you are manipulating were
created
> without namespace awareness. Could that be the case?
> The xsd prefix is not so presumptuous considering the Primer example:
> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> This special case is only there to avoid the use "Q" for the special schema
> namespace itself.
> The change you show doesn't look right. The code is written to avoid using
"xsd"
> if it's being used for something else already. A Q prefix will be
introduced in
> the case of adding a declaration with a namespace not previously used or in
the
> case that "xsd" is used for something else...
> The important question here is why is the guarded failing to find an existing
> xmlns declaration? I suspect it has to do with namespace awareness in how
the DOM
> was constructed...
> Hayden Marchant wrote:
> > Ed,
> >
> > Shouldn't the code read:
> >
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xsd"))
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > }
> > return "xsd";
> >
> > as opposed to :
> >
> > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xsd"))
> > {
> > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:xsd", namespace);
> > return "xsd";
> > }
> >
> > i.e. when I debugged the code, I got to this method call. My schema
> > element does have the relevant attribute set to 'xsd'. So the code does
> > not need to call setAttributeNS and should return nicely. However, it
> > carries on a resets a duplicate namespace for XSD.
> >
> > In my opinion, it's a simple bug - I made a local change in my copy of the
> > eclipse src and it sort of solved it. Am I talking sense?
> >
> > I am still not clear of the case that the code is ever supposed to get to
> > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > more correct to check ALL of the attributes, and if there exists an
> > attribute that has a valid value for
> > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> > of that attribute should be returned as the namespace for that method.
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > In XSDConcreteComponentImpl there is this method:
> >
> > > protected String niceCreateNamespaceAttribute(String namespace)
> > > {
> > > XSDSchema xsdSchema = getSchema();
> > > if (namespace == null)
> > > {
> > > namespace = "";
> > > }
> > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > {
> > > Element schemaElement = xsdSchema.getElement();
> > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > {
> > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xsd"))
> >
> > > {
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:xsd", namespace);
> > > return "xsd";
> > > }
> > > }
> >
> > > String qualifier = "Q";
> > > int count = 1;
> > > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:" + qualifier + count))
> > > {
> > > ++count;
> > > }
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:"
+
> > > qualifier + count, namespace);
> > > return qualifier + count;
> > > }
> > > else
> > > {
> > > return null;
> > > }
> > > }
> >
> > > It's called from one place that looks like this:
> >
> > > String qualifier = XSDConstants.lookupQualifier(element,
namespace);
> > > if (qualifier == null)
> > > {
> > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > }
> >
> > > So it should create a new xmlns declaration only if there isn't already
one.
> >
> > > I'm not sure how the duplication can happen given this algorithm...
> >
> > > Hayden Marchant wrote:
> >
> > > > I am merging the contents of schemas by iterating over the elements of
the
> > > > referred schemas of a certain base schema and adding all the contents
of
> > > > them into the base schema. Here is a snippet of my code:
> > > >
> > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > >
> > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > iterator.hasNext();) {
> > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > >
> > > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > }
> > > >
> > > > This code works nicely. However, sometimes when I run this code, I get
a
> > > > weird phenomenom. The root of the schema becomes:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > >
> > > > I have no idea where this Q1 comes from, but lots of the xsd elements
from
> > > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > >
> > > > Also, when validating this schema, all elements that are of type
> > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > > seems to have been some duplication of XMLSchema namespaces when
objects
> > > > were moved over.
> > > >
> > > > Any idea what I may be doing wrong?
> > > >
> > > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #578617 is a reply to message #30389] |
Mon, 29 September 2003 18:30 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hayden,
There is a significant hole in the editing support that editing changes don't
propagate across schemas. So if you delete something from an included schema, the
including schema won't know about that. You should restrict editing to the "root"
schema, i.e., the one that includes and imports the others; or you need to rebuild
model for the schemas affected by the change. There should probably be a method on
XSDSchema that forces such a recomputation to happen...
Hayden Marchant wrote:
> I'm still getting another related problem - in fact, I have cornered it
> down quite a specific scenario:
>
> 1. Load a simple XSDSchema, for example:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> xmlns="http://ACORD.org/Standards/Life/2"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="unqualified" attributeFormDefault="unqualified">
> <xsd:complexType name="INQUIRY_LEVEL_CODES">
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="tc" use="required">
> <xsd:simpleType>
> <xsd:restriction base="xsd:nonNegativeInteger">
> <xsd:enumeration value="1"/>
> <xsd:enumeration value="2"/>
> <xsd:enumeration value="3"/>
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:attribute>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> <xsd:element name="VendorName">
> <xsd:complexType>
> <xsd:simpleContent>
> <xsd:extension base="xsd:string">
> <xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
> </xsd:extension>
> </xsd:simpleContent>
> </xsd:complexType>
> </xsd:element>
> </xsd:schema>
>
> The schema is valid 100% and has no diagnostics.
>
> 2. Load an XSDSchema2 that has nested includes.
> 3. Remove elements from both this schemas and some of the includes (if I
> only remove from this schema and NOT from includes, bug does not happen).
> 4. dump the pruned main XSDSchema2 to an OutputStream.
> 5. Repeat step 1 - this step the same schema has the following diagnostic:
>
> Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
> unresolved.
>
> Basically, Eclipse XSD seems to break after removing items from nested
> schemas. I cna't isolate this bug to such an extent that I can send a
> reproducable code but above is that basic scenario. Has anyone come across
> something like this?
>
> Thanks
>
> Ed Merks wrote:
>
> > Hayden,
>
> > Sorry for the earlier miss send.
>
> > As I indicated in my previous note, the method is called from a guard:
>
> > protected void niceSetAttributeURIValue(Element element, String attribute,
> > String uriList)
> > {
> > ....
> > String qualifier = XSDConstants.lookupQualifier(element, namespace);
> > if (qualifier == null)
> > {
> > qualifier = niceCreateNamespaceAttribute(namespace);
> > }
>
> > So if there is an xmlns declaration already for the namespace, it should be
> used.
> > I.e., all the attributes are checked as you suggest.
>
> > I have a strong suspicion that the DOM elements you are manipulating were
> created
> > without namespace awareness. Could that be the case?
>
> > The xsd prefix is not so presumptuous considering the Primer example:
>
> > http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
>
> > This special case is only there to avoid the use "Q" for the special schema
> > namespace itself.
>
> > The change you show doesn't look right. The code is written to avoid using
> "xsd"
> > if it's being used for something else already. A Q prefix will be
> introduced in
> > the case of adding a declaration with a namespace not previously used or in
> the
> > case that "xsd" is used for something else...
>
> > The important question here is why is the guarded failing to find an existing
> > xmlns declaration? I suspect it has to do with namespace awareness in how
> the DOM
> > was constructed...
>
> > Hayden Marchant wrote:
>
> > > Ed,
> > >
> > > Shouldn't the code read:
> > >
> > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xsd"))
> > > {
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:xsd", namespace);
> > > }
> > > return "xsd";
> > >
> > > as opposed to :
> > >
> > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xsd"))
> > > {
> > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xmlns:xsd", namespace);
> > > return "xsd";
> > > }
> > >
> > > i.e. when I debugged the code, I got to this method call. My schema
> > > element does have the relevant attribute set to 'xsd'. So the code does
> > > not need to call setAttributeNS and should return nicely. However, it
> > > carries on a resets a duplicate namespace for XSD.
> > >
> > > In my opinion, it's a simple bug - I made a local change in my copy of the
> > > eclipse src and it sort of solved it. Am I talking sense?
> > >
> > > I am still not clear of the case that the code is ever supposed to get to
> > > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > > more correct to check ALL of the attributes, and if there exists an
> > > attribute that has a valid value for
> > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the name
> > > of that attribute should be returned as the namespace for that method.
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > In XSDConcreteComponentImpl there is this method:
> > >
> > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > {
> > > > XSDSchema xsdSchema = getSchema();
> > > > if (namespace == null)
> > > > {
> > > > namespace = "";
> > > > }
> > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > {
> > > > Element schemaElement = xsdSchema.getElement();
> > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > {
> > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > "xsd"))
> > >
> > > > {
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:xsd", namespace);
> > > > return "xsd";
> > > > }
> > > > }
> > >
> > > > String qualifier = "Q";
> > > > int count = 1;
> > > > while (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:" + qualifier + count))
> > > > {
> > > > ++count;
> > > > }
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000, "xmlns:"
> +
> > > > qualifier + count, namespace);
> > > > return qualifier + count;
> > > > }
> > > > else
> > > > {
> > > > return null;
> > > > }
> > > > }
> > >
> > > > It's called from one place that looks like this:
> > >
> > > > String qualifier = XSDConstants.lookupQualifier(element,
> namespace);
> > > > if (qualifier == null)
> > > > {
> > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > }
> > >
> > > > So it should create a new xmlns declaration only if there isn't already
> one.
> > >
> > > > I'm not sure how the duplication can happen given this algorithm...
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I am merging the contents of schemas by iterating over the elements of
> the
> > > > > referred schemas of a certain base schema and adding all the contents
> of
> > > > > them into the base schema. Here is a snippet of my code:
> > > > >
> > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > >
> > > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > > iterator.hasNext();) {
> > > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > > >
> > > > > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > }
> > > > >
> > > > > This code works nicely. However, sometimes when I run this code, I get
> a
> > > > > weird phenomenom. The root of the schema becomes:
> > > > >
> > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > >
> > > > > I have no idea where this Q1 comes from, but lots of the xsd elements
> from
> > > > > the XMLSchema schema are prefixed with Q1 instead of xsd. Sometimes the
> > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > >
> > > > > Also, when validating this schema, all elements that are of type
> > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse. There
> > > > > seems to have been some duplication of XMLSchema namespaces when
> objects
> > > > > were moved over.
> > > > >
> > > > > Any idea what I may be doing wrong?
> > > > >
> > > > > Thanks
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #578818 is a reply to message #30461] |
Tue, 30 September 2003 04:42 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
The hold in editing support is not a problem for me - I delete lots of
items from included schemas, and then I move all of the elements from the
included schemas into the main including schema and then I save the new
schema. So I don't need to tell the including schema that an included
schema changed since ?I then dump everything all into the including schema
after that anyway.
The idea is that there's a very large XSD standard which is spread over a
few documents. The XSD Standard is too big to be validated against, so
several legal subsets of this standard need to be generated acording to
certain criteria - this is what I'm doing. I chop off the irrelevant parts
of the schema whilst making sure I don't leave any bad bits hanging. Then
I merge all the smaller schemas into 1 large schema. There is not a
problem with this - it works great. The problem is, is that after doing
this action, when I open another extremely trivial schema that Eclipse was
very happy with before, I now get errors. In a different JVM the small
schema is fine, it's just that after doing the removing of elements and
merging that the Eclipse parser seems to 'break'.
Any ideas how I can proceed, or maybe that's enough suspicions to look
into a certain part. Again, it looks like the xsd namespace -
http://www.w3.org/2001/XMLSchema seems to have been duplicated or lost or
something, as can be seen from the diagnostic that I got below with the
perfectly legal xsd.
Thanks,
Ed Merks wrote:
> Hayden,
> There is a significant hole in the editing support that editing changes don't
> propagate across schemas. So if you delete something from an included
schema, the
> including schema won't know about that. You should restrict editing to the
"root"
> schema, i.e., the one that includes and imports the others; or you need to
rebuild
> model for the schemas affected by the change. There should probably be a
method on
> XSDSchema that forces such a recomputation to happen...
> Hayden Marchant wrote:
> > I'm still getting another related problem - in fact, I have cornered it
> > down quite a specific scenario:
> >
> > 1. Load a simple XSDSchema, for example:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > xmlns="http://ACORD.org/Standards/Life/2"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > <xsd:complexType name="INQUIRY_LEVEL_CODES">
> > <xsd:simpleContent>
> > <xsd:extension base="xsd:string">
> > <xsd:attribute name="tc" use="required">
> > <xsd:simpleType>
> > <xsd:restriction base="xsd:nonNegativeInteger">
> > <xsd:enumeration value="1"/>
> > <xsd:enumeration value="2"/>
> > <xsd:enumeration value="3"/>
> > </xsd:restriction>
> > </xsd:simpleType>
> > </xsd:attribute>
> > </xsd:extension>
> > </xsd:simpleContent>
> > </xsd:complexType>
> > <xsd:element name="VendorName">
> > <xsd:complexType>
> > <xsd:simpleContent>
> > <xsd:extension base="xsd:string">
> > <xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
> > </xsd:extension>
> > </xsd:simpleContent>
> > </xsd:complexType>
> > </xsd:element>
> > </xsd:schema>
> >
> > The schema is valid 100% and has no diagnostics.
> >
> > 2. Load an XSDSchema2 that has nested includes.
> > 3. Remove elements from both this schemas and some of the includes (if I
> > only remove from this schema and NOT from includes, bug does not happen).
> > 4. dump the pruned main XSDSchema2 to an OutputStream.
> > 5. Repeat step 1 - this step the same schema has the following diagnostic:
> >
> > Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
> > unresolved.
> >
> > Basically, Eclipse XSD seems to break after removing items from nested
> > schemas. I cna't isolate this bug to such an extent that I can send a
> > reproducable code but above is that basic scenario. Has anyone come across
> > something like this?
> >
> > Thanks
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > Sorry for the earlier miss send.
> >
> > > As I indicated in my previous note, the method is called from a guard:
> >
> > > protected void niceSetAttributeURIValue(Element element, String
attribute,
> > > String uriList)
> > > {
> > > ....
> > > String qualifier = XSDConstants.lookupQualifier(element,
namespace);
> > > if (qualifier == null)
> > > {
> > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > }
> >
> > > So if there is an xmlns declaration already for the namespace, it should
be
> > used.
> > > I.e., all the attributes are checked as you suggest.
> >
> > > I have a strong suspicion that the DOM elements you are manipulating were
> > created
> > > without namespace awareness. Could that be the case?
> >
> > > The xsd prefix is not so presumptuous considering the Primer example:
> >
> > >
http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> >
> > > This special case is only there to avoid the use "Q" for the special
schema
> > > namespace itself.
> >
> > > The change you show doesn't look right. The code is written to avoid
using
> > "xsd"
> > > if it's being used for something else already. A Q prefix will be
> > introduced in
> > > the case of adding a declaration with a namespace not previously used or
in
> > the
> > > case that "xsd" is used for something else...
> >
> > > The important question here is why is the guarded failing to find an
existing
> > > xmlns declaration? I suspect it has to do with namespace awareness in
how
> > the DOM
> > > was constructed...
> >
> > > Hayden Marchant wrote:
> >
> > > > Ed,
> > > >
> > > > Shouldn't the code read:
> > > >
> > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xsd"))
> > > > {
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:xsd", namespace);
> > > > }
> > > > return "xsd";
> > > >
> > > > as opposed to :
> > > >
> > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xsd"))
> > > > {
> > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xmlns:xsd", namespace);
> > > > return "xsd";
> > > > }
> > > >
> > > > i.e. when I debugged the code, I got to this method call. My schema
> > > > element does have the relevant attribute set to 'xsd'. So the code does
> > > > not need to call setAttributeNS and should return nicely. However, it
> > > > carries on a resets a duplicate namespace for XSD.
> > > >
> > > > In my opinion, it's a simple bug - I made a local change in my copy of
the
> > > > eclipse src and it sort of solved it. Am I talking sense?
> > > >
> > > > I am still not clear of the case that the code is ever supposed to get
to
> > > > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > > > more correct to check ALL of the attributes, and if there exists an
> > > > attribute that has a valid value for
> > > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the
name
> > > > of that attribute should be returned as the namespace for that method.
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > In XSDConcreteComponentImpl there is this method:
> > > >
> > > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > > {
> > > > > XSDSchema xsdSchema = getSchema();
> > > > > if (namespace == null)
> > > > > {
> > > > > namespace = "";
> > > > > }
> > > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > > {
> > > > > Element schemaElement = xsdSchema.getElement();
> > > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > > {
> > > > > if
(!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > "xsd"))
> > > >
> > > > > {
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:xsd", namespace);
> > > > > return "xsd";
> > > > > }
> > > > > }
> > > >
> > > > > String qualifier = "Q";
> > > > > int count = 1;
> > > > > while
(schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:" + qualifier + count))
> > > > > {
> > > > > ++count;
> > > > > }
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
"xmlns:"
> > +
> > > > > qualifier + count, namespace);
> > > > > return qualifier + count;
> > > > > }
> > > > > else
> > > > > {
> > > > > return null;
> > > > > }
> > > > > }
> > > >
> > > > > It's called from one place that looks like this:
> > > >
> > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > namespace);
> > > > > if (qualifier == null)
> > > > > {
> > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > }
> > > >
> > > > > So it should create a new xmlns declaration only if there isn't
already
> > one.
> > > >
> > > > > I'm not sure how the duplication can happen given this algorithm...
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > I am merging the contents of schemas by iterating over the
elements of
> > the
> > > > > > referred schemas of a certain base schema and adding all the
contents
> > of
> > > > > > them into the base schema. Here is a snippet of my code:
> > > > > >
> > > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > > >
> > > > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > > > iterator.hasNext();) {
> > > > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > > > >
> > > > > >
primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > > }
> > > > > >
> > > > > > This code works nicely. However, sometimes when I run this code, I
get
> > a
> > > > > > weird phenomenom. The root of the schema becomes:
> > > > > >
> > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > > elementFormDefault="unqualified"
attributeFormDefault="unqualified">
> > > > > >
> > > > > > I have no idea where this Q1 comes from, but lots of the xsd
elements
> > from
> > > > > > the XMLSchema schema are prefixed with Q1 instead of xsd.
Sometimes the
> > > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > > >
> > > > > > Also, when validating this schema, all elements that are of type
> > > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
There
> > > > > > seems to have been some duplication of XMLSchema namespaces when
> > objects
> > > > > > were moved over.
> > > > > >
> > > > > > Any idea what I may be doing wrong?
> > > > > >
> > > > > > Thanks
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #578885 is a reply to message #30635] |
Tue, 30 September 2003 12:00 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Hayden,
It sounds like perhaps maybe the schema for schemas itself got edited
accidentally. It lives in global resource set with static lifetime. It's the
schema returned by XSDSchema.getSchemaForSchema. You could try adding an
org.eclipse.emf.ecore.util.EContentAdapter to it and putting a print statement in
the notifyChanged method to see if maybe some of your code is accidentally editing
it.
Hayden Marchant wrote:
> The hold in editing support is not a problem for me - I delete lots of
> items from included schemas, and then I move all of the elements from the
> included schemas into the main including schema and then I save the new
> schema. So I don't need to tell the including schema that an included
> schema changed since ?I then dump everything all into the including schema
> after that anyway.
>
> The idea is that there's a very large XSD standard which is spread over a
> few documents. The XSD Standard is too big to be validated against, so
> several legal subsets of this standard need to be generated acording to
> certain criteria - this is what I'm doing. I chop off the irrelevant parts
> of the schema whilst making sure I don't leave any bad bits hanging. Then
> I merge all the smaller schemas into 1 large schema. There is not a
> problem with this - it works great. The problem is, is that after doing
> this action, when I open another extremely trivial schema that Eclipse was
> very happy with before, I now get errors. In a different JVM the small
> schema is fine, it's just that after doing the removing of elements and
> merging that the Eclipse parser seems to 'break'.
>
> Any ideas how I can proceed, or maybe that's enough suspicions to look
> into a certain part. Again, it looks like the xsd namespace -
> http://www.w3.org/2001/XMLSchema seems to have been duplicated or lost or
> something, as can be seen from the diagnostic that I got below with the
> perfectly legal xsd.
>
> Thanks,
>
> Ed Merks wrote:
>
> > Hayden,
>
> > There is a significant hole in the editing support that editing changes don't
> > propagate across schemas. So if you delete something from an included
> schema, the
> > including schema won't know about that. You should restrict editing to the
> "root"
> > schema, i.e., the one that includes and imports the others; or you need to
> rebuild
> > model for the schemas affected by the change. There should probably be a
> method on
> > XSDSchema that forces such a recomputation to happen...
>
> > Hayden Marchant wrote:
>
> > > I'm still getting another related problem - in fact, I have cornered it
> > > down quite a specific scenario:
> > >
> > > 1. Load a simple XSDSchema, for example:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > xmlns="http://ACORD.org/Standards/Life/2"
> > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > <xsd:complexType name="INQUIRY_LEVEL_CODES">
> > > <xsd:simpleContent>
> > > <xsd:extension base="xsd:string">
> > > <xsd:attribute name="tc" use="required">
> > > <xsd:simpleType>
> > > <xsd:restriction base="xsd:nonNegativeInteger">
> > > <xsd:enumeration value="1"/>
> > > <xsd:enumeration value="2"/>
> > > <xsd:enumeration value="3"/>
> > > </xsd:restriction>
> > > </xsd:simpleType>
> > > </xsd:attribute>
> > > </xsd:extension>
> > > </xsd:simpleContent>
> > > </xsd:complexType>
> > > <xsd:element name="VendorName">
> > > <xsd:complexType>
> > > <xsd:simpleContent>
> > > <xsd:extension base="xsd:string">
> > > <xsd:attribute name="VendorCode" type="xsd:string" use="required"/>
> > > </xsd:extension>
> > > </xsd:simpleContent>
> > > </xsd:complexType>
> > > </xsd:element>
> > > </xsd:schema>
> > >
> > > The schema is valid 100% and has no diagnostics.
> > >
> > > 2. Load an XSDSchema2 that has nested includes.
> > > 3. Remove elements from both this schemas and some of the includes (if I
> > > only remove from this schema and NOT from includes, bug does not happen).
> > > 4. dump the pruned main XSDSchema2 to an OutputStream.
> > > 5. Repeat step 1 - this step the same schema has the following diagnostic:
> > >
> > > Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string' is
> > > unresolved.
> > >
> > > Basically, Eclipse XSD seems to break after removing items from nested
> > > schemas. I cna't isolate this bug to such an extent that I can send a
> > > reproducable code but above is that basic scenario. Has anyone come across
> > > something like this?
> > >
> > > Thanks
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > Sorry for the earlier miss send.
> > >
> > > > As I indicated in my previous note, the method is called from a guard:
> > >
> > > > protected void niceSetAttributeURIValue(Element element, String
> attribute,
> > > > String uriList)
> > > > {
> > > > ....
> > > > String qualifier = XSDConstants.lookupQualifier(element,
> namespace);
> > > > if (qualifier == null)
> > > > {
> > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > }
> > >
> > > > So if there is an xmlns declaration already for the namespace, it should
> be
> > > used.
> > > > I.e., all the attributes are checked as you suggest.
> > >
> > > > I have a strong suspicion that the DOM elements you are manipulating were
> > > created
> > > > without namespace awareness. Could that be the case?
> > >
> > > > The xsd prefix is not so presumptuous considering the Primer example:
> > >
> > > >
> http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> > >
> > > > This special case is only there to avoid the use "Q" for the special
> schema
> > > > namespace itself.
> > >
> > > > The change you show doesn't look right. The code is written to avoid
> using
> > > "xsd"
> > > > if it's being used for something else already. A Q prefix will be
> > > introduced in
> > > > the case of adding a declaration with a namespace not previously used or
> in
> > > the
> > > > case that "xsd" is used for something else...
> > >
> > > > The important question here is why is the guarded failing to find an
> existing
> > > > xmlns declaration? I suspect it has to do with namespace awareness in
> how
> > > the DOM
> > > > was constructed...
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > Ed,
> > > > >
> > > > > Shouldn't the code read:
> > > > >
> > > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xsd"))
> > > > > {
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:xsd", namespace);
> > > > > }
> > > > > return "xsd";
> > > > >
> > > > > as opposed to :
> > > > >
> > > > > if (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xsd"))
> > > > > {
> > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xmlns:xsd", namespace);
> > > > > return "xsd";
> > > > > }
> > > > >
> > > > > i.e. when I debugged the code, I got to this method call. My schema
> > > > > element does have the relevant attribute set to 'xsd'. So the code does
> > > > > not need to call setAttributeNS and should return nicely. However, it
> > > > > carries on a resets a duplicate namespace for XSD.
> > > > >
> > > > > In my opinion, it's a simple bug - I made a local change in my copy of
> the
> > > > > eclipse src and it sort of solved it. Am I talking sense?
> > > > >
> > > > > I am still not clear of the case that the code is ever supposed to get
> to
> > > > > make a "Q" XSD namespace. Also isn't it a bit presumptious that the XSD
> > > > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't it be
> > > > > more correct to check ALL of the attributes, and if there exists an
> > > > > attribute that has a valid value for
> > > > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and the
> name
> > > > > of that attribute should be returned as the namespace for that method.
> > > > >
> > > > > Ed Merks wrote:
> > > > >
> > > > > > Hayden,
> > > > >
> > > > > > In XSDConcreteComponentImpl there is this method:
> > > > >
> > > > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > > > {
> > > > > > XSDSchema xsdSchema = getSchema();
> > > > > > if (namespace == null)
> > > > > > {
> > > > > > namespace = "";
> > > > > > }
> > > > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > > > {
> > > > > > Element schemaElement = xsdSchema.getElement();
> > > > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > > > {
> > > > > > if
> (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > "xsd"))
> > > > >
> > > > > > {
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:xsd", namespace);
> > > > > > return "xsd";
> > > > > > }
> > > > > > }
> > > > >
> > > > > > String qualifier = "Q";
> > > > > > int count = 1;
> > > > > > while
> (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:" + qualifier + count))
> > > > > > {
> > > > > > ++count;
> > > > > > }
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> "xmlns:"
> > > +
> > > > > > qualifier + count, namespace);
> > > > > > return qualifier + count;
> > > > > > }
> > > > > > else
> > > > > > {
> > > > > > return null;
> > > > > > }
> > > > > > }
> > > > >
> > > > > > It's called from one place that looks like this:
> > > > >
> > > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > > namespace);
> > > > > > if (qualifier == null)
> > > > > > {
> > > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > > }
> > > > >
> > > > > > So it should create a new xmlns declaration only if there isn't
> already
> > > one.
> > > > >
> > > > > > I'm not sure how the duplication can happen given this algorithm...
> > > > >
> > > > > > Hayden Marchant wrote:
> > > > >
> > > > > > > I am merging the contents of schemas by iterating over the
> elements of
> > > the
> > > > > > > referred schemas of a certain base schema and adding all the
> contents
> > > of
> > > > > > > them into the base schema. Here is a snippet of my code:
> > > > > > >
> > > > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > > > >
> > > > > > > for (Iterator iterator = fReferencedXsdSchemas.iterator();
> > > > > > > iterator.hasNext();) {
> > > > > > > XSDSchema referredSchema = (XSDSchema) iterator.next();
> > > > > > >
> > > > > > >
> primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > > > }
> > > > > > >
> > > > > > > This code works nicely. However, sometimes when I run this code, I
> get
> > > a
> > > > > > > weird phenomenom. The root of the schema becomes:
> > > > > > >
> > > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > > > elementFormDefault="unqualified"
> attributeFormDefault="unqualified">
> > > > > > >
> > > > > > > I have no idea where this Q1 comes from, but lots of the xsd
> elements
> > > from
> > > > > > > the XMLSchema schema are prefixed with Q1 instead of xsd.
> Sometimes the
> > > > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > > > >
> > > > > > > Also, when validating this schema, all elements that are of type
> > > > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
> There
> > > > > > > seems to have been some duplication of XMLSchema namespaces when
> > > objects
> > > > > > > were moved over.
> > > > > > >
> > > > > > > Any idea what I may be doing wrong?
> > > > > > >
> > > > > > > Thanks
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Weird namespaces when moving objects between XSD schemas [message #578965 is a reply to message #30705] |
Tue, 30 September 2003 12:54 |
Hayden Marchant
Messages: 90
Registered: July 2009 |
Member |
|
|
Ed,
You pointed me in exactly the right direction - you were correct in your
analysis - I was removing some quite vital parts of the static schema.
That probably solves the Q1 namespace problem aswell.
Thanks so much for your help.
I'm glad it was a bug in my code and not in Eclipse :)
Ed Merks wrote:
> Hayden,
> It sounds like perhaps maybe the schema for schemas itself got edited
> accidentally. It lives in global resource set with static lifetime. It's
the
> schema returned by XSDSchema.getSchemaForSchema. You could try adding an
> org.eclipse.emf.ecore.util.EContentAdapter to it and putting a print
statement in
> the notifyChanged method to see if maybe some of your code is accidentally
editing
> it.
> Hayden Marchant wrote:
> > The hold in editing support is not a problem for me - I delete lots of
> > items from included schemas, and then I move all of the elements from the
> > included schemas into the main including schema and then I save the new
> > schema. So I don't need to tell the including schema that an included
> > schema changed since ?I then dump everything all into the including schema
> > after that anyway.
> >
> > The idea is that there's a very large XSD standard which is spread over a
> > few documents. The XSD Standard is too big to be validated against, so
> > several legal subsets of this standard need to be generated acording to
> > certain criteria - this is what I'm doing. I chop off the irrelevant parts
> > of the schema whilst making sure I don't leave any bad bits hanging. Then
> > I merge all the smaller schemas into 1 large schema. There is not a
> > problem with this - it works great. The problem is, is that after doing
> > this action, when I open another extremely trivial schema that Eclipse was
> > very happy with before, I now get errors. In a different JVM the small
> > schema is fine, it's just that after doing the removing of elements and
> > merging that the Eclipse parser seems to 'break'.
> >
> > Any ideas how I can proceed, or maybe that's enough suspicions to look
> > into a certain part. Again, it looks like the xsd namespace -
> > http://www.w3.org/2001/XMLSchema seems to have been duplicated or lost or
> > something, as can be seen from the diagnostic that I got below with the
> > perfectly legal xsd.
> >
> > Thanks,
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > There is a significant hole in the editing support that editing changes
don't
> > > propagate across schemas. So if you delete something from an included
> > schema, the
> > > including schema won't know about that. You should restrict editing to
the
> > "root"
> > > schema, i.e., the one that includes and imports the others; or you need
to
> > rebuild
> > > model for the schemas affected by the change. There should probably be a
> > method on
> > > XSDSchema that forces such a recomputation to happen...
> >
> > > Hayden Marchant wrote:
> >
> > > > I'm still getting another related problem - in fact, I have cornered it
> > > > down quite a specific scenario:
> > > >
> > > > 1. Load a simple XSDSchema, for example:
> > > >
> > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > elementFormDefault="unqualified" attributeFormDefault="unqualified">
> > > > <xsd:complexType name="INQUIRY_LEVEL_CODES">
> > > > <xsd:simpleContent>
> > > > <xsd:extension base="xsd:string">
> > > > <xsd:attribute name="tc" use="required">
> > > > <xsd:simpleType>
> > > > <xsd:restriction base="xsd:nonNegativeInteger">
> > > > <xsd:enumeration value="1"/>
> > > > <xsd:enumeration value="2"/>
> > > > <xsd:enumeration value="3"/>
> > > > </xsd:restriction>
> > > > </xsd:simpleType>
> > > > </xsd:attribute>
> > > > </xsd:extension>
> > > > </xsd:simpleContent>
> > > > </xsd:complexType>
> > > > <xsd:element name="VendorName">
> > > > <xsd:complexType>
> > > > <xsd:simpleContent>
> > > > <xsd:extension base="xsd:string">
> > > > <xsd:attribute name="VendorCode" type="xsd:string"
use="required"/>
> > > > </xsd:extension>
> > > > </xsd:simpleContent>
> > > > </xsd:complexType>
> > > > </xsd:element>
> > > > </xsd:schema>
> > > >
> > > > The schema is valid 100% and has no diagnostics.
> > > >
> > > > 2. Load an XSDSchema2 that has nested includes.
> > > > 3. Remove elements from both this schemas and some of the includes (if
I
> > > > only remove from this schema and NOT from includes, bug does not
happen).
> > > > 4. dump the pruned main XSDSchema2 to an OutputStream.
> > > > 5. Repeat step 1 - this step the same schema has the following
diagnostic:
> > > >
> > > > Line 11: XSD: Type reference 'http://www.w3.org/2001/XMLSchema#string'
is
> > > > unresolved.
> > > >
> > > > Basically, Eclipse XSD seems to break after removing items from nested
> > > > schemas. I cna't isolate this bug to such an extent that I can send a
> > > > reproducable code but above is that basic scenario. Has anyone come
across
> > > > something like this?
> > > >
> > > > Thanks
> > > >
> > > > Ed Merks wrote:
> > > >
> > > > > Hayden,
> > > >
> > > > > Sorry for the earlier miss send.
> > > >
> > > > > As I indicated in my previous note, the method is called from a
guard:
> > > >
> > > > > protected void niceSetAttributeURIValue(Element element, String
> > attribute,
> > > > > String uriList)
> > > > > {
> > > > > ....
> > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > namespace);
> > > > > if (qualifier == null)
> > > > > {
> > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > }
> > > >
> > > > > So if there is an xmlns declaration already for the namespace, it
should
> > be
> > > > used.
> > > > > I.e., all the attributes are checked as you suggest.
> > > >
> > > > > I have a strong suspicion that the DOM elements you are manipulating
were
> > > > created
> > > > > without namespace awareness. Could that be the case?
> > > >
> > > > > The xsd prefix is not so presumptuous considering the Primer example:
> > > >
> > > > >
> > http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/primer.ht ml#POSchema
> > > >
> > > > > This special case is only there to avoid the use "Q" for the special
> > schema
> > > > > namespace itself.
> > > >
> > > > > The change you show doesn't look right. The code is written to avoid
> > using
> > > > "xsd"
> > > > > if it's being used for something else already. A Q prefix will be
> > > > introduced in
> > > > > the case of adding a declaration with a namespace not previously
used or
> > in
> > > > the
> > > > > case that "xsd" is used for something else...
> > > >
> > > > > The important question here is why is the guarded failing to find an
> > existing
> > > > > xmlns declaration? I suspect it has to do with namespace awareness
in
> > how
> > > > the DOM
> > > > > was constructed...
> > > >
> > > > > Hayden Marchant wrote:
> > > >
> > > > > > Ed,
> > > > > >
> > > > > > Shouldn't the code read:
> > > > > >
> > > > > > if
(!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xsd"))
> > > > > > {
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:xsd", namespace);
> > > > > > }
> > > > > > return "xsd";
> > > > > >
> > > > > > as opposed to :
> > > > > >
> > > > > > if
(!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xsd"))
> > > > > > {
> > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xmlns:xsd", namespace);
> > > > > > return "xsd";
> > > > > > }
> > > > > >
> > > > > > i.e. when I debugged the code, I got to this method call. My schema
> > > > > > element does have the relevant attribute set to 'xsd'. So the code
does
> > > > > > not need to call setAttributeNS and should return nicely. However,
it
> > > > > > carries on a resets a duplicate namespace for XSD.
> > > > > >
> > > > > > In my opinion, it's a simple bug - I made a local change in my
copy of
> > the
> > > > > > eclipse src and it sort of solved it. Am I talking sense?
> > > > > >
> > > > > > I am still not clear of the case that the code is ever supposed to
get
> > to
> > > > > > make a "Q" XSD namespace. Also isn't it a bit presumptious that
the XSD
> > > > > > namespace is 'xsd'? It could just as easily be 'xs', no? Mightn't
it be
> > > > > > more correct to check ALL of the attributes, and if there exists an
> > > > > > attribute that has a valid value for
> > > > > > XSDConstants.isSchemaForSchemaNamespace() then that's the one and
the
> > name
> > > > > > of that attribute should be returned as the namespace for that
method.
> > > > > >
> > > > > > Ed Merks wrote:
> > > > > >
> > > > > > > Hayden,
> > > > > >
> > > > > > > In XSDConcreteComponentImpl there is this method:
> > > > > >
> > > > > > > protected String niceCreateNamespaceAttribute(String namespace)
> > > > > > > {
> > > > > > > XSDSchema xsdSchema = getSchema();
> > > > > > > if (namespace == null)
> > > > > > > {
> > > > > > > namespace = "";
> > > > > > > }
> > > > > > > if (xsdSchema != null && xsdSchema.getElement() != null)
> > > > > > > {
> > > > > > > Element schemaElement = xsdSchema.getElement();
> > > > > > > if (XSDConstants.isSchemaForSchemaNamespace(namespace))
> > > > > > > {
> > > > > > > if
> > (!schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > "xsd"))
> > > > > >
> > > > > > > {
> > > > > > >
schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > > "xmlns:xsd", namespace);
> > > > > > > return "xsd";
> > > > > > > }
> > > > > > > }
> > > > > >
> > > > > > > String qualifier = "Q";
> > > > > > > int count = 1;
> > > > > > > while
> > (schemaElement.hasAttributeNS(XSDConstants.XMLNS_URI_2000,
> > > > > > > "xmlns:" + qualifier + count))
> > > > > > > {
> > > > > > > ++count;
> > > > > > > }
> > > > > > > schemaElement.setAttributeNS(XSDConstants.XMLNS_URI_2000,
> > "xmlns:"
> > > > +
> > > > > > > qualifier + count, namespace);
> > > > > > > return qualifier + count;
> > > > > > > }
> > > > > > > else
> > > > > > > {
> > > > > > > return null;
> > > > > > > }
> > > > > > > }
> > > > > >
> > > > > > > It's called from one place that looks like this:
> > > > > >
> > > > > > > String qualifier = XSDConstants.lookupQualifier(element,
> > > > namespace);
> > > > > > > if (qualifier == null)
> > > > > > > {
> > > > > > > qualifier = niceCreateNamespaceAttribute(namespace);
> > > > > > > }
> > > > > >
> > > > > > > So it should create a new xmlns declaration only if there isn't
> > already
> > > > one.
> > > > > >
> > > > > > > I'm not sure how the duplication can happen given this
algorithm...
> > > > > >
> > > > > > > Hayden Marchant wrote:
> > > > > >
> > > > > > > > I am merging the contents of schemas by iterating over the
> > elements of
> > > > the
> > > > > > > > referred schemas of a certain base schema and adding all the
> > contents
> > > > of
> > > > > > > > them into the base schema. Here is a snippet of my code:
> > > > > > > >
> > > > > > > > XSDSchema primaryXSDSchema = getEclipseXSDSchema();
> > > > > > > >
> > > > > > > > for (Iterator iterator =
fReferencedXsdSchemas.iterator();
> > > > > > > > iterator.hasNext();) {
> > > > > > > > XSDSchema referredSchema = (XSDSchema)
iterator.next();
> > > > > > > >
> > > > > > > >
> > primaryXSDSchema.getContents().addAll(referredSchema.getCont ents());
> > > > > > > > }
> > > > > > > >
> > > > > > > > This code works nicely. However, sometimes when I run this
code, I
> > get
> > > > a
> > > > > > > > weird phenomenom. The root of the schema becomes:
> > > > > > > >
> > > > > > > > <?xml version="1.0" encoding="UTF-8"?>
> > > > > > > > <xsd:schema targetNamespace="http://ACORD.org/Standards/Life/2"
> > > > > > > > xmlns:Q1="http://www.w3.org/2001/XMLSchema"
> > > > > > > > xmlns="http://ACORD.org/Standards/Life/2"
> > > > > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > > > > elementFormDefault="unqualified"
> > attributeFormDefault="unqualified">
> > > > > > > >
> > > > > > > > I have no idea where this Q1 comes from, but lots of the xsd
> > elements
> > > > from
> > > > > > > > the XMLSchema schema are prefixed with Q1 instead of xsd.
> > Sometimes the
> > > > > > > > whole schema is Q1. e.g. <Q1:schema>.....
> > > > > > > >
> > > > > > > > Also, when validating this schema, all elements that are of
type
> > > > > > > > <Q1:string>, <Q1:integer> etc... cannot be resolved by Eclipse.
> > There
> > > > > > > > seems to have been some duplication of XMLSchema namespaces
when
> > > > objects
> > > > > > > > were moved over.
> > > > > > > >
> > > > > > > > Any idea what I may be doing wrong?
> > > > > > > >
> > > > > > > > Thanks
|
|
|
Goto Forum:
Current Time: Fri Apr 19 01:51:56 GMT 2024
Powered by FUDForum. Page generated in 0.04075 seconds |
] 
Search
Help
Register
Login
Home
