unexpected differences with/without target namespace [message #29088] |
Wed, 10 September 2003 16:29 |
Eclipse User |
|
|
|
Originally posted by: ihc.sas-glas.mottmac.com
I am surprised by some failures I am getting which only occur when a
targetNamespace is declared but disappear when I remove the
targetNamespace declaration.
Two examples:
1) a complex type has an attribute reference to a simple xsd:integer
attribute. XSD provides an AttributeUse with an AttributeDeclaration.
WITHOUT a target namespace declaration at the top level, the
AttributeDeclaration has as typeDefintion an XSDSimpleTypeDefinitionImpl
with name "integer", fine.
WITH a target namespace declaration at the top level, the same
typeDefiniion field is null.
See end for the schema for this example
2) an element with complex type defined within element as extending
another complex type.
WITHOUT a target namespace declaration at the top level, the
XSDElementDeclaration has as typeDefinition an
XSDComplexTypeDefinitionImpl.
WITH a target namespace the same typeDefinition field is null.
These nulls appear to doom a call to getEClassifier to throw a
NullPointerException as discussed in a previous post.
Complete Schema for 1)
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.example.com/Library"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:attribute name = "InterchangeTime" type = "xsd:integer">
<xsd:annotation>
<xsd:documentation>Time (minutes) between VehicleJourneys or for travelling
within/between Clusters</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:complexType name="Book">
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="pages" type="xsd:int"/>
</xsd:sequence>
<xsd:attribute ref = "InterchangeTime" use = "required"/>
</xsd:complexType>
</xsd:schema>
Ian
|
|
|
Re: unexpected differences with/without target namespace [message #29172 is a reply to message #29088] |
Wed, 10 September 2003 19:07 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Ian,
When the target namespace was null, the implicit xmlns="" declaration allows you to reference the name
without a prefix, but when you define a target namespace, you need to define an xmlns prefix for that
namespace and youneed to use that prefix to reference any name in the namespace.
Ian Cornwell wrote:
> I am surprised by some failures I am getting which only occur when a
> targetNamespace is declared but disappear when I remove the
> targetNamespace declaration.
>
> Two examples:
>
> 1) a complex type has an attribute reference to a simple xsd:integer
> attribute. XSD provides an AttributeUse with an AttributeDeclaration.
>
> WITHOUT a target namespace declaration at the top level, the
> AttributeDeclaration has as typeDefintion an XSDSimpleTypeDefinitionImpl
> with name "integer", fine.
>
> WITH a target namespace declaration at the top level, the same
> typeDefiniion field is null.
>
> See end for the schema for this example
>
> 2) an element with complex type defined within element as extending
> another complex type.
>
> WITHOUT a target namespace declaration at the top level, the
> XSDElementDeclaration has as typeDefinition an
> XSDComplexTypeDefinitionImpl.
>
> WITH a target namespace the same typeDefinition field is null.
>
> These nulls appear to doom a call to getEClassifier to throw a
> NullPointerException as discussed in a previous post.
>
> Complete Schema for 1)
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://www.example.com/Library"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>
> <xsd:attribute name = "InterchangeTime" type = "xsd:integer">
> <xsd:annotation>
> <xsd:documentation>Time (minutes) between VehicleJourneys or for travelling
> within/between Clusters</xsd:documentation>
> </xsd:annotation>
> </xsd:attribute>
> <xsd:complexType name="Book">
> <xsd:sequence>
> <xsd:element name="title" type="xsd:string"/>
> <xsd:element name="pages" type="xsd:int"/>
> </xsd:sequence>
> <xsd:attribute ref = "InterchangeTime" use = "required"/>
> </xsd:complexType>
> </xsd:schema>
>
> Ian
|
|
|
Re: unexpected differences with/without target namespace [message #29285 is a reply to message #29172] |
Thu, 11 September 2003 08:40 |
Eclipse User |
|
|
|
Originally posted by: ihc.sas-glas.mottmac.com
Oops sorry that was an easy one, the fact that the actual declarations do
not need to be qualified led me to think that references also default to
the target namespace - which (as you say) they do not. My schema did
validate using XSV, which is strange, because when I went back to check
the XML Schema spec part 1 it appears to say that the ref must be
qualified, unless you have an xmlns=. Oh well, I'm glad to have ben wrong
here and I will be less reliant on XSV in future. Thanks.
Ed Merks wrote:
> Ian,
> When the target namespace was null, the implicit xmlns="" declaration allows
you to reference the name
> without a prefix, but when you define a target namespace, you need to define
an xmlns prefix for that
> namespace and youneed to use that prefix to reference any name in the
namespace.
> Ian Cornwell wrote:
> > I am surprised by some failures I am getting which only occur when a
> > targetNamespace is declared but disappear when I remove the
> > targetNamespace declaration.
> >
> > Two examples:
> >
> > 1) a complex type has an attribute reference to a simple xsd:integer
> > attribute. XSD provides an AttributeUse with an AttributeDeclaration.
> >
> > WITHOUT a target namespace declaration at the top level, the
> > AttributeDeclaration has as typeDefintion an XSDSimpleTypeDefinitionImpl
> > with name "integer", fine.
> >
> > WITH a target namespace declaration at the top level, the same
> > typeDefiniion field is null.
> >
> > See end for the schema for this example
> >
> > 2) an element with complex type defined within element as extending
> > another complex type.
> >
> > WITHOUT a target namespace declaration at the top level, the
> > XSDElementDeclaration has as typeDefinition an
> > XSDComplexTypeDefinitionImpl.
> >
> > WITH a target namespace the same typeDefinition field is null.
> >
> > These nulls appear to doom a call to getEClassifier to throw a
> > NullPointerException as discussed in a previous post.
> >
> > Complete Schema for 1)
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsd:schema targetNamespace="http://www.example.com/Library"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> >
> > <xsd:attribute name = "InterchangeTime" type = "xsd:integer">
> > <xsd:annotation>
> > <xsd:documentation>Time (minutes) between
VehicleJourneys or for travelling
> > within/between Clusters</xsd:documentation>
> > </xsd:annotation>
> > </xsd:attribute>
> > <xsd:complexType name="Book">
> > <xsd:sequence>
> > <xsd:element name="title" type="xsd:string"/>
> > <xsd:element name="pages" type="xsd:int"/>
> > </xsd:sequence>
> > <xsd:attribute ref = "InterchangeTime" use = "required"/>
> > </xsd:complexType>
> > </xsd:schema>
> >
> > Ian
|
|
|
Re: unexpected differences with/without target namespace [message #577708 is a reply to message #29088] |
Wed, 10 September 2003 19:07 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
Ian,
When the target namespace was null, the implicit xmlns="" declaration allows you to reference the name
without a prefix, but when you define a target namespace, you need to define an xmlns prefix for that
namespace and youneed to use that prefix to reference any name in the namespace.
Ian Cornwell wrote:
> I am surprised by some failures I am getting which only occur when a
> targetNamespace is declared but disappear when I remove the
> targetNamespace declaration.
>
> Two examples:
>
> 1) a complex type has an attribute reference to a simple xsd:integer
> attribute. XSD provides an AttributeUse with an AttributeDeclaration.
>
> WITHOUT a target namespace declaration at the top level, the
> AttributeDeclaration has as typeDefintion an XSDSimpleTypeDefinitionImpl
> with name "integer", fine.
>
> WITH a target namespace declaration at the top level, the same
> typeDefiniion field is null.
>
> See end for the schema for this example
>
> 2) an element with complex type defined within element as extending
> another complex type.
>
> WITHOUT a target namespace declaration at the top level, the
> XSDElementDeclaration has as typeDefinition an
> XSDComplexTypeDefinitionImpl.
>
> WITH a target namespace the same typeDefinition field is null.
>
> These nulls appear to doom a call to getEClassifier to throw a
> NullPointerException as discussed in a previous post.
>
> Complete Schema for 1)
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema targetNamespace="http://www.example.com/Library"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
>
> <xsd:attribute name = "InterchangeTime" type = "xsd:integer">
> <xsd:annotation>
> <xsd:documentation>Time (minutes) between VehicleJourneys or for travelling
> within/between Clusters</xsd:documentation>
> </xsd:annotation>
> </xsd:attribute>
> <xsd:complexType name="Book">
> <xsd:sequence>
> <xsd:element name="title" type="xsd:string"/>
> <xsd:element name="pages" type="xsd:int"/>
> </xsd:sequence>
> <xsd:attribute ref = "InterchangeTime" use = "required"/>
> </xsd:complexType>
> </xsd:schema>
>
> Ian
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: unexpected differences with/without target namespace [message #577873 is a reply to message #29172] |
Thu, 11 September 2003 08:40 |
Eclipse User |
|
|
|
Originally posted by: ihc.sas-glas.mottmac.com
Oops sorry that was an easy one, the fact that the actual declarations do
not need to be qualified led me to think that references also default to
the target namespace - which (as you say) they do not. My schema did
validate using XSV, which is strange, because when I went back to check
the XML Schema spec part 1 it appears to say that the ref must be
qualified, unless you have an xmlns=. Oh well, I'm glad to have ben wrong
here and I will be less reliant on XSV in future. Thanks.
Ed Merks wrote:
> Ian,
> When the target namespace was null, the implicit xmlns="" declaration allows
you to reference the name
> without a prefix, but when you define a target namespace, you need to define
an xmlns prefix for that
> namespace and youneed to use that prefix to reference any name in the
namespace.
> Ian Cornwell wrote:
> > I am surprised by some failures I am getting which only occur when a
> > targetNamespace is declared but disappear when I remove the
> > targetNamespace declaration.
> >
> > Two examples:
> >
> > 1) a complex type has an attribute reference to a simple xsd:integer
> > attribute. XSD provides an AttributeUse with an AttributeDeclaration.
> >
> > WITHOUT a target namespace declaration at the top level, the
> > AttributeDeclaration has as typeDefintion an XSDSimpleTypeDefinitionImpl
> > with name "integer", fine.
> >
> > WITH a target namespace declaration at the top level, the same
> > typeDefiniion field is null.
> >
> > See end for the schema for this example
> >
> > 2) an element with complex type defined within element as extending
> > another complex type.
> >
> > WITHOUT a target namespace declaration at the top level, the
> > XSDElementDeclaration has as typeDefinition an
> > XSDComplexTypeDefinitionImpl.
> >
> > WITH a target namespace the same typeDefinition field is null.
> >
> > These nulls appear to doom a call to getEClassifier to throw a
> > NullPointerException as discussed in a previous post.
> >
> > Complete Schema for 1)
> > <?xml version="1.0" encoding="UTF-8"?>
> > <xsd:schema targetNamespace="http://www.example.com/Library"
> > xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> >
> > <xsd:attribute name = "InterchangeTime" type = "xsd:integer">
> > <xsd:annotation>
> > <xsd:documentation>Time (minutes) between
VehicleJourneys or for travelling
> > within/between Clusters</xsd:documentation>
> > </xsd:annotation>
> > </xsd:attribute>
> > <xsd:complexType name="Book">
> > <xsd:sequence>
> > <xsd:element name="title" type="xsd:string"/>
> > <xsd:element name="pages" type="xsd:int"/>
> > </xsd:sequence>
> > <xsd:attribute ref = "InterchangeTime" use = "required"/>
> > </xsd:complexType>
> > </xsd:schema>
> >
> > Ian
|
|
|
Powered by
FUDForum. Page generated in 0.04590 seconds