Home » Archived » XML Schema Definition (XSD) » unresolved element ref
| unresolved element ref [message #54437] |
Tue, 02 November 2004 20:30  |
Eclipse User |
|
|
|
Originally posted by: jtaylor.nextance.com
If I have a schema that uses an element reference that is invalid (i.e.
the file containing the element declaration was mistakenly not included),
how can I detect this from the XSDElementDeclaration instance? The
instance seems to be in a strange state in which it has no container and
is not considered an element reference (i.e.
XSDElementDeclaration.isElementDeclarationReference() returns false). Is
this a bug?
Thanks,
James
|
|
| |
| Re: unresolved element ref [message #54491 is a reply to message #54464] |
Wed, 03 November 2004 18:18  |
| Eclipse User |
|
|
|
Originally posted by: jtaylor.nextance.com
Ed,
After the schema is loaded, the unresolved element reference is not any
where in the model. It seems that this placeholder has replaced it. If I
fully traverse all terms, none of them statisfy the
isElementDeclarationReference check. However, validate is able to point
out that the element reference is not resolved. Is that expected? How
can I recognize an unresolved element reference when I'm traversing a
schema? Thanks,
James
Ed Merks wrote:
> James,
> An element reference that can't be resolved will result in the creation
> of a detached placeholder that acts as the resolved element
> declaration. It is not considered a reference, since it resolves to
> itself, and is not part of any schema.
> Unresolved element references are diagnosed like this in
> XSDElementDeclarationImpl.validate
> if (isElementDeclarationReference())
> {
> XSDElementDeclaration theResolvedElementDeclaration =
> getResolvedElementDeclaration();
> if (theResolvedElementDeclaration.getContainer() == null)
> {
> createDiagnostic
> (XSDDiagnosticSeverity.ERROR_LITERAL,
> "_UI_UnresolvedElementDeclaration_message",
> theResolvedElementDeclaration.getURI());
> }
> James Taylor wrote:
>> If I have a schema that uses an element reference that is invalid
>> (i.e. the file containing the element declaration was mistakenly not
>> included), how can I detect this from the XSDElementDeclaration
>> instance? The instance seems to be in a strange state in which it has
>> no container and is not considered an element reference (i.e.
>> XSDElementDeclaration.isElementDeclarationReference() returns false).
>> Is this a bug?
>>
>> Thanks,
>>
>> James
>>
|
|
|
| Re: unresolved element ref [message #54517 is a reply to message #54491] |
Thu, 04 November 2004 07:01 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------010806070904040103020303
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
James,
The key here seems to be *how *you are traversing the schema. A black
diamond/containment reference cannot reach a detached placeholder,
otherwise the placeholder would have a parent/container and would not be
detached. So your traversal of the schema must be visiting non-black
diamond/non-containment references (which could lead to circularity).
Perhaps you are walking directly from a particle to its term rather than
from the particle to its particle content; if the particle content is an
element reference, the term will be the resolved element declaration,
i.e., a placeholder in the case of an element reference that fails to
resolve.
James Taylor wrote:
> Ed,
>
> After the schema is loaded, the unresolved element reference is not
> any where in the model. It seems that this placeholder has replaced
> it. If I fully traverse all terms, none of them statisfy the
> isElementDeclarationReference check. However, validate is able to
> point out that the element reference is not resolved. Is that
> expected? How can I recognize an unresolved element reference when
> I'm traversing a schema? Thanks,
>
> James
>
> Ed Merks wrote:
>
>> James,
>
>
>> An element reference that can't be resolved will result in the
>> creation of a detached placeholder that acts as the resolved element
>> declaration. It is not considered a reference, since it resolves to
>> itself, and is not part of any schema.
>
>
>> Unresolved element references are diagnosed like this in
>> XSDElementDeclarationImpl.validate
>
>
>> if (isElementDeclarationReference())
>> {
>> XSDElementDeclaration theResolvedElementDeclaration =
>> getResolvedElementDeclaration();
>> if (theResolvedElementDeclaration.getContainer() == null)
>> {
>> createDiagnostic
>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>> "_UI_UnresolvedElementDeclaration_message",
>> theResolvedElementDeclaration.getURI());
>> }
>
>
>
>> James Taylor wrote:
>
>
>>> If I have a schema that uses an element reference that is invalid
>>> (i.e. the file containing the element declaration was mistakenly not
>>> included), how can I detect this from the XSDElementDeclaration
>>> instance? The instance seems to be in a strange state in which it
>>> has no container and is not considered an element reference (i.e.
>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>> false). Is this a bug?
>>>
>>> Thanks,
>>>
>>> James
>>>
>
>
--------------010806070904040103020303
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
James,<br>
<br>
The key here seems to be <b>how </b>you are traversing the schema.
|
|
|
| Re: unresolved element ref [message #54544 is a reply to message #54517] |
Fri, 05 November 2004 03:20 |
| Eclipse User |
|
|
|
Originally posted by: jtaylor.nextance.com
Ed,
Yes, you are exactly right -- I am walking from a particle directly to its
term. If I navigate the black diamon/containment references for
components like attribute groups and model group definitions, how are
cycles handled? I realize that they are not allowed, but if one is
encountered, how do I detect this case? Will the isCycle() indicate this
and if so, does it do so only on references, or would an attribute group
that has indirect recursion indicate that it is a cyclical on the
definition?
Thanks,
James
Ed Merks wrote:
> James,
> The key here seems to be *how *you are traversing the schema. A black
> diamond/containment reference cannot reach a detached placeholder,
> otherwise the placeholder would have a parent/container and would not be
> detached. So your traversal of the schema must be visiting non-black
> diamond/non-containment references (which could lead to circularity).
> Perhaps you are walking directly from a particle to its term rather than
> from the particle to its particle content; if the particle content is an
> element reference, the term will be the resolved element declaration,
> i.e., a placeholder in the case of an element reference that fails to
> resolve.
> James Taylor wrote:
>> Ed,
>>
>> After the schema is loaded, the unresolved element reference is not
>> any where in the model. It seems that this placeholder has replaced
>> it. If I fully traverse all terms, none of them statisfy the
>> isElementDeclarationReference check. However, validate is able to
>> point out that the element reference is not resolved. Is that
>> expected? How can I recognize an unresolved element reference when
>> I'm traversing a schema? Thanks,
>>
>> James
>>
>> Ed Merks wrote:
>>
>>> James,
>>
>>
>>> An element reference that can't be resolved will result in the
>>> creation of a detached placeholder that acts as the resolved element
>>> declaration. It is not considered a reference, since it resolves to
>>> itself, and is not part of any schema.
>>
>>
>>> Unresolved element references are diagnosed like this in
>>> XSDElementDeclarationImpl.validate
>>
>>
>>> if (isElementDeclarationReference())
>>> {
>>> XSDElementDeclaration theResolvedElementDeclaration =
>>> getResolvedElementDeclaration();
>>> if (theResolvedElementDeclaration.getContainer() == null)
>>> {
>>> createDiagnostic
>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>> "_UI_UnresolvedElementDeclaration_message",
>>> theResolvedElementDeclaration.getURI());
>>> }
>>
>>
>>
>>> James Taylor wrote:
>>
>>
>>>> If I have a schema that uses an element reference that is invalid
>>>> (i.e. the file containing the element declaration was mistakenly not
>>>> included), how can I detect this from the XSDElementDeclaration
>>>> instance? The instance seems to be in a strange state in which it
>>>> has no container and is not considered an element reference (i.e.
>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>> false). Is this a bug?
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>
>>
|
|
|
| Re: unresolved element ref [message #54571 is a reply to message #54544] |
Fri, 05 November 2004 07:55 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------090003090607010804080900
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
James,
These two methods can be used to check for circularity before you even
traverse:
XSDRedefinableComponent.isCircular:
* This indicates whether the definition is circular,
* e.g., circular base, item, or member types reference,
* circular attribute group definition reference,
* or circular model group definition reference.
XSDElementDeclaration.isCircular:
* This indicates that the element declaration is part of an invalid
circular substitution group.
So yes, you can check for an attribute group being circular. Even
without circularity, the same model group can be used more than once in
a content model, so you may want to prevent multiple visits of the same
object by keeping track of those already been visited....
James Taylor wrote:
> Ed,
>
> Yes, you are exactly right -- I am walking from a particle directly to
> its term. If I navigate the black diamon/containment references for
> components like attribute groups and model group definitions, how are
> cycles handled? I realize that they are not allowed, but if one is
> encountered, how do I detect this case? Will the isCycle() indicate
> this and if so, does it do so only on references, or would an
> attribute group that has indirect recursion indicate that it is a
> cyclical on the definition?
>
> Thanks,
>
> James
>
> Ed Merks wrote:
>
>> James,
>
>
>> The key here seems to be *how *you are traversing the schema. A
>> black diamond/containment reference cannot reach a detached
>> placeholder, otherwise the placeholder would have a parent/container
>> and would not be detached. So your traversal of the schema must be
>> visiting non-black diamond/non-containment references (which could
>> lead to circularity). Perhaps you are walking directly from a
>> particle to its term rather than from the particle to its particle
>> content; if the particle content is an element reference, the term
>> will be the resolved element declaration, i.e., a placeholder in the
>> case of an element reference that fails to resolve.
>
>
>
>> James Taylor wrote:
>
>
>>> Ed,
>>>
>>> After the schema is loaded, the unresolved element reference is not
>>> any where in the model. It seems that this placeholder has replaced
>>> it. If I fully traverse all terms, none of them statisfy the
>>> isElementDeclarationReference check. However, validate is able to
>>> point out that the element reference is not resolved. Is that
>>> expected? How can I recognize an unresolved element reference when
>>> I'm traversing a schema? Thanks,
>>>
>>> James
>>>
>>> Ed Merks wrote:
>>>
>>>> James,
>>>
>>>
>>>
>>>> An element reference that can't be resolved will result in the
>>>> creation of a detached placeholder that acts as the resolved
>>>> element declaration. It is not considered a reference, since it
>>>> resolves to itself, and is not part of any schema.
>>>
>>>
>>>
>>>> Unresolved element references are diagnosed like this in
>>>> XSDElementDeclarationImpl.validate
>>>
>>>
>>>
>>>> if (isElementDeclarationReference())
>>>> {
>>>> XSDElementDeclaration theResolvedElementDeclaration =
>>>> getResolvedElementDeclaration();
>>>> if (theResolvedElementDeclaration.getContainer() == null)
>>>> {
>>>> createDiagnostic
>>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>>> "_UI_UnresolvedElementDeclaration_message",
>>>> theResolvedElementDeclaration.getURI());
>>>> }
>>>
>>>
>>>
>>>
>>>> James Taylor wrote:
>>>
>>>
>>>
>>>>> If I have a schema that uses an element reference that is invalid
>>>>> (i.e. the file containing the element declaration was mistakenly
>>>>> not included), how can I detect this from the
>>>>> XSDElementDeclaration instance? The instance seems to be in a
>>>>> strange state in which it has no container and is not considered
>>>>> an element reference (i.e.
>>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>>> false). Is this a bug?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> James
>>>>>
>>>
>>>
>
>
--------------090003090607010804080900
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
James,<br>
<br>
These two methods can be used to check for circularity before you even
traverse:<br>
<br>
XSDRedefinableComponent.isCircular:<br>
<blockquote>
|
|
|
| Re: unresolved element ref [message #54595 is a reply to message #54571] |
Sun, 07 November 2004 15:56 |
| Eclipse User |
|
|
|
Originally posted by: jtaylor.nextance.com
Ed,
I've modified my traversal to use the black diamon/containment references
and it works well now. However, I have a similar problem when traversing
from a type to its base type. If the base type isn't resolved, then the
type using this base type seems to not be contained by any schema. Is
there a different relationship I should be traversing? Thanks,
James
Ed Merks wrote:
> James,
> These two methods can be used to check for circularity before you even
> traverse:
> XSDRedefinableComponent.isCircular:
> * This indicates whether the definition is circular,
> * e.g., circular base, item, or member types reference,
> * circular attribute group definition reference,
> * or circular model group definition reference.
> XSDElementDeclaration.isCircular:
> * This indicates that the element declaration is part of an invalid
> circular substitution group.
> So yes, you can check for an attribute group being circular. Even
> without circularity, the same model group can be used more than once in
> a content model, so you may want to prevent multiple visits of the same
> object by keeping track of those already been visited....
> James Taylor wrote:
>> Ed,
>>
>> Yes, you are exactly right -- I am walking from a particle directly to
>> its term. If I navigate the black diamon/containment references for
>> components like attribute groups and model group definitions, how are
>> cycles handled? I realize that they are not allowed, but if one is
>> encountered, how do I detect this case? Will the isCycle() indicate
>> this and if so, does it do so only on references, or would an
>> attribute group that has indirect recursion indicate that it is a
>> cyclical on the definition?
>>
>> Thanks,
>>
>> James
>>
>> Ed Merks wrote:
>>
>>> James,
>>
>>
>>> The key here seems to be *how *you are traversing the schema. A
>>> black diamond/containment reference cannot reach a detached
>>> placeholder, otherwise the placeholder would have a parent/container
>>> and would not be detached. So your traversal of the schema must be
>>> visiting non-black diamond/non-containment references (which could
>>> lead to circularity). Perhaps you are walking directly from a
>>> particle to its term rather than from the particle to its particle
>>> content; if the particle content is an element reference, the term
>>> will be the resolved element declaration, i.e., a placeholder in the
>>> case of an element reference that fails to resolve.
>>
>>
>>
>>> James Taylor wrote:
>>
>>
>>>> Ed,
>>>>
>>>> After the schema is loaded, the unresolved element reference is not
>>>> any where in the model. It seems that this placeholder has replaced
>>>> it. If I fully traverse all terms, none of them statisfy the
>>>> isElementDeclarationReference check. However, validate is able to
>>>> point out that the element reference is not resolved. Is that
>>>> expected? How can I recognize an unresolved element reference when
>>>> I'm traversing a schema? Thanks,
>>>>
>>>> James
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> James,
>>>>
>>>>
>>>>
>>>>> An element reference that can't be resolved will result in the
>>>>> creation of a detached placeholder that acts as the resolved
>>>>> element declaration. It is not considered a reference, since it
>>>>> resolves to itself, and is not part of any schema.
>>>>
>>>>
>>>>
>>>>> Unresolved element references are diagnosed like this in
>>>>> XSDElementDeclarationImpl.validate
>>>>
>>>>
>>>>
>>>>> if (isElementDeclarationReference())
>>>>> {
>>>>> XSDElementDeclaration theResolvedElementDeclaration =
>>>>> getResolvedElementDeclaration();
>>>>> if (theResolvedElementDeclaration.getContainer() == null)
>>>>> {
>>>>> createDiagnostic
>>>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>>>> "_UI_UnresolvedElementDeclaration_message",
>>>>> theResolvedElementDeclaration.getURI());
>>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>> James Taylor wrote:
>>>>
>>>>
>>>>
>>>>>> If I have a schema that uses an element reference that is invalid
>>>>>> (i.e. the file containing the element declaration was mistakenly
>>>>>> not included), how can I detect this from the
>>>>>> XSDElementDeclaration instance? The instance seems to be in a
>>>>>> strange state in which it has no container and is not considered
>>>>>> an element reference (i.e.
>>>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>>>> false). Is this a bug?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> James
>>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: unresolved element ref [message #54620 is a reply to message #54595] |
Mon, 08 November 2004 07:06 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
James,
No, it's the place holder representing the unresolved base type itself
that won't be contained by a schema; the type that you reached via black
diamond containment from the schema will be attached and will reference
something that isn't...
James Taylor wrote:
> Ed,
>
> I've modified my traversal to use the black diamon/containment
> references and it works well now. However, I have a similar problem
> when traversing from a type to its base type. If the base type isn't
> resolved, then the type using this base type seems to not be contained
> by any schema. Is there a different relationship I should be
> traversing? Thanks,
>
> James
>
> Ed Merks wrote:
>
>> James,
>
>
>> These two methods can be used to check for circularity before you
>> even traverse:
>
>
>> XSDRedefinableComponent.isCircular:
>
>
>> * This indicates whether the definition is circular,
>> * e.g., circular base, item, or member types reference,
>> * circular attribute group definition reference,
>> * or circular model group definition reference.
>
>
>> XSDElementDeclaration.isCircular:
>
>
>> * This indicates that the element declaration is part of an invalid
>> circular substitution group.
>
>
>> So yes, you can check for an attribute group being circular. Even
>> without circularity, the same model group can be used more than once
>> in a content model, so you may want to prevent multiple visits of the
>> same object by keeping track of those already been visited....
>
>
>
>> James Taylor wrote:
>
>
>>> Ed,
>>>
>>> Yes, you are exactly right -- I am walking from a particle directly
>>> to its term. If I navigate the black diamon/containment references
>>> for components like attribute groups and model group definitions,
>>> how are cycles handled? I realize that they are not allowed, but if
>>> one is encountered, how do I detect this case? Will the isCycle()
>>> indicate this and if so, does it do so only on references, or would
>>> an attribute group that has indirect recursion indicate that it is a
>>> cyclical on the definition?
>>>
>>> Thanks,
>>>
>>> James
>>>
>>> Ed Merks wrote:
>>>
>>>> James,
>>>
>>>
>>>
>>>> The key here seems to be *how *you are traversing the schema. A
>>>> black diamond/containment reference cannot reach a detached
>>>> placeholder, otherwise the placeholder would have a
>>>> parent/container and would not be detached. So your traversal of
>>>> the schema must be visiting non-black diamond/non-containment
>>>> references (which could lead to circularity). Perhaps you are
>>>> walking directly from a particle to its term rather than from the
>>>> particle to its particle content; if the particle content is an
>>>> element reference, the term will be the resolved element
>>>> declaration, i.e., a placeholder in the case of an element
>>>> reference that fails to resolve.
>>>
>>>
>>>
>>>
>>>> James Taylor wrote:
>>>
>>>
>>>
>>>>> Ed,
>>>>>
>>>>> After the schema is loaded, the unresolved element reference is
>>>>> not any where in the model. It seems that this placeholder has
>>>>> replaced it. If I fully traverse all terms, none of them statisfy
>>>>> the isElementDeclarationReference check. However, validate is
>>>>> able to point out that the element reference is not resolved. Is
>>>>> that expected? How can I recognize an unresolved element
>>>>> reference when I'm traversing a schema? Thanks,
>>>>>
>>>>> James
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> James,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> An element reference that can't be resolved will result in the
>>>>>> creation of a detached placeholder that acts as the resolved
>>>>>> element declaration. It is not considered a reference, since it
>>>>>> resolves to itself, and is not part of any schema.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Unresolved element references are diagnosed like this in
>>>>>> XSDElementDeclarationImpl.validate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> if (isElementDeclarationReference())
>>>>>> {
>>>>>> XSDElementDeclaration theResolvedElementDeclaration =
>>>>>> getResolvedElementDeclaration();
>>>>>> if (theResolvedElementDeclaration.getContainer() == null)
>>>>>> {
>>>>>> createDiagnostic
>>>>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>>>>> "_UI_UnresolvedElementDeclaration_message",
>>>>>> theResolvedElementDeclaration.getURI());
>>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> James Taylor wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> If I have a schema that uses an element reference that is
>>>>>>> invalid (i.e. the file containing the element declaration was
>>>>>>> mistakenly not included), how can I detect this from the
>>>>>>> XSDElementDeclaration instance? The instance seems to be in a
>>>>>>> strange state in which it has no container and is not considered
>>>>>>> an element reference (i.e.
>>>>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>>>>> false). Is this a bug?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
| Re: unresolved element ref [message #592331 is a reply to message #54437] |
Wed, 03 November 2004 07:04 |
| Eclipse User |
|
|
|
James,
An element reference that can't be resolved will result in the creation
of a detached placeholder that acts as the resolved element
declaration. It is not considered a reference, since it resolves to
itself, and is not part of any schema.
Unresolved element references are diagnosed like this in
XSDElementDeclarationImpl.validate
if (isElementDeclarationReference())
{
XSDElementDeclaration theResolvedElementDeclaration =
getResolvedElementDeclaration();
if (theResolvedElementDeclaration.getContainer() == null)
{
createDiagnostic
(XSDDiagnosticSeverity.ERROR_LITERAL,
"_UI_UnresolvedElementDeclaration_message",
theResolvedElementDeclaration.getURI());
}
James Taylor wrote:
> If I have a schema that uses an element reference that is invalid
> (i.e. the file containing the element declaration was mistakenly not
> included), how can I detect this from the XSDElementDeclaration
> instance? The instance seems to be in a strange state in which it has
> no container and is not considered an element reference (i.e.
> XSDElementDeclaration.isElementDeclarationReference() returns false).
> Is this a bug?
>
> Thanks,
>
> James
>
|
|
|
| Re: unresolved element ref [message #592343 is a reply to message #54464] |
Wed, 03 November 2004 18:18 |
| Eclipse User |
|
|
|
Ed,
After the schema is loaded, the unresolved element reference is not any
where in the model. It seems that this placeholder has replaced it. If I
fully traverse all terms, none of them statisfy the
isElementDeclarationReference check. However, validate is able to point
out that the element reference is not resolved. Is that expected? How
can I recognize an unresolved element reference when I'm traversing a
schema? Thanks,
James
Ed Merks wrote:
> James,
> An element reference that can't be resolved will result in the creation
> of a detached placeholder that acts as the resolved element
> declaration. It is not considered a reference, since it resolves to
> itself, and is not part of any schema.
> Unresolved element references are diagnosed like this in
> XSDElementDeclarationImpl.validate
> if (isElementDeclarationReference())
> {
> XSDElementDeclaration theResolvedElementDeclaration =
> getResolvedElementDeclaration();
> if (theResolvedElementDeclaration.getContainer() == null)
> {
> createDiagnostic
> (XSDDiagnosticSeverity.ERROR_LITERAL,
> "_UI_UnresolvedElementDeclaration_message",
> theResolvedElementDeclaration.getURI());
> }
> James Taylor wrote:
>> If I have a schema that uses an element reference that is invalid
>> (i.e. the file containing the element declaration was mistakenly not
>> included), how can I detect this from the XSDElementDeclaration
>> instance? The instance seems to be in a strange state in which it has
>> no container and is not considered an element reference (i.e.
>> XSDElementDeclaration.isElementDeclarationReference() returns false).
>> Is this a bug?
>>
>> Thanks,
>>
>> James
>>
|
|
|
| Re: unresolved element ref [message #592356 is a reply to message #54491] |
Thu, 04 November 2004 07:01 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------010806070904040103020303
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
James,
The key here seems to be *how *you are traversing the schema. A black
diamond/containment reference cannot reach a detached placeholder,
otherwise the placeholder would have a parent/container and would not be
detached. So your traversal of the schema must be visiting non-black
diamond/non-containment references (which could lead to circularity).
Perhaps you are walking directly from a particle to its term rather than
from the particle to its particle content; if the particle content is an
element reference, the term will be the resolved element declaration,
i.e., a placeholder in the case of an element reference that fails to
resolve.
James Taylor wrote:
> Ed,
>
> After the schema is loaded, the unresolved element reference is not
> any where in the model. It seems that this placeholder has replaced
> it. If I fully traverse all terms, none of them statisfy the
> isElementDeclarationReference check. However, validate is able to
> point out that the element reference is not resolved. Is that
> expected? How can I recognize an unresolved element reference when
> I'm traversing a schema? Thanks,
>
> James
>
> Ed Merks wrote:
>
>> James,
>
>
>> An element reference that can't be resolved will result in the
>> creation of a detached placeholder that acts as the resolved element
>> declaration. It is not considered a reference, since it resolves to
>> itself, and is not part of any schema.
>
>
>> Unresolved element references are diagnosed like this in
>> XSDElementDeclarationImpl.validate
>
>
>> if (isElementDeclarationReference())
>> {
>> XSDElementDeclaration theResolvedElementDeclaration =
>> getResolvedElementDeclaration();
>> if (theResolvedElementDeclaration.getContainer() == null)
>> {
>> createDiagnostic
>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>> "_UI_UnresolvedElementDeclaration_message",
>> theResolvedElementDeclaration.getURI());
>> }
>
>
>
>> James Taylor wrote:
>
>
>>> If I have a schema that uses an element reference that is invalid
>>> (i.e. the file containing the element declaration was mistakenly not
>>> included), how can I detect this from the XSDElementDeclaration
>>> instance? The instance seems to be in a strange state in which it
>>> has no container and is not considered an element reference (i.e.
>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>> false). Is this a bug?
>>>
>>> Thanks,
>>>
>>> James
>>>
>
>
--------------010806070904040103020303
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
James,<br>
<br>
The key here seems to be <b>how </b>you are traversing the schema.
|
|
|
| Re: unresolved element ref [message #592368 is a reply to message #54517] |
Fri, 05 November 2004 03:20 |
| Eclipse User |
|
|
|
Ed,
Yes, you are exactly right -- I am walking from a particle directly to its
term. If I navigate the black diamon/containment references for
components like attribute groups and model group definitions, how are
cycles handled? I realize that they are not allowed, but if one is
encountered, how do I detect this case? Will the isCycle() indicate this
and if so, does it do so only on references, or would an attribute group
that has indirect recursion indicate that it is a cyclical on the
definition?
Thanks,
James
Ed Merks wrote:
> James,
> The key here seems to be *how *you are traversing the schema. A black
> diamond/containment reference cannot reach a detached placeholder,
> otherwise the placeholder would have a parent/container and would not be
> detached. So your traversal of the schema must be visiting non-black
> diamond/non-containment references (which could lead to circularity).
> Perhaps you are walking directly from a particle to its term rather than
> from the particle to its particle content; if the particle content is an
> element reference, the term will be the resolved element declaration,
> i.e., a placeholder in the case of an element reference that fails to
> resolve.
> James Taylor wrote:
>> Ed,
>>
>> After the schema is loaded, the unresolved element reference is not
>> any where in the model. It seems that this placeholder has replaced
>> it. If I fully traverse all terms, none of them statisfy the
>> isElementDeclarationReference check. However, validate is able to
>> point out that the element reference is not resolved. Is that
>> expected? How can I recognize an unresolved element reference when
>> I'm traversing a schema? Thanks,
>>
>> James
>>
>> Ed Merks wrote:
>>
>>> James,
>>
>>
>>> An element reference that can't be resolved will result in the
>>> creation of a detached placeholder that acts as the resolved element
>>> declaration. It is not considered a reference, since it resolves to
>>> itself, and is not part of any schema.
>>
>>
>>> Unresolved element references are diagnosed like this in
>>> XSDElementDeclarationImpl.validate
>>
>>
>>> if (isElementDeclarationReference())
>>> {
>>> XSDElementDeclaration theResolvedElementDeclaration =
>>> getResolvedElementDeclaration();
>>> if (theResolvedElementDeclaration.getContainer() == null)
>>> {
>>> createDiagnostic
>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>> "_UI_UnresolvedElementDeclaration_message",
>>> theResolvedElementDeclaration.getURI());
>>> }
>>
>>
>>
>>> James Taylor wrote:
>>
>>
>>>> If I have a schema that uses an element reference that is invalid
>>>> (i.e. the file containing the element declaration was mistakenly not
>>>> included), how can I detect this from the XSDElementDeclaration
>>>> instance? The instance seems to be in a strange state in which it
>>>> has no container and is not considered an element reference (i.e.
>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>> false). Is this a bug?
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>
>>
|
|
|
| Re: unresolved element ref [message #592383 is a reply to message #54544] |
Fri, 05 November 2004 07:55 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------090003090607010804080900
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
James,
These two methods can be used to check for circularity before you even
traverse:
XSDRedefinableComponent.isCircular:
* This indicates whether the definition is circular,
* e.g., circular base, item, or member types reference,
* circular attribute group definition reference,
* or circular model group definition reference.
XSDElementDeclaration.isCircular:
* This indicates that the element declaration is part of an invalid
circular substitution group.
So yes, you can check for an attribute group being circular. Even
without circularity, the same model group can be used more than once in
a content model, so you may want to prevent multiple visits of the same
object by keeping track of those already been visited....
James Taylor wrote:
> Ed,
>
> Yes, you are exactly right -- I am walking from a particle directly to
> its term. If I navigate the black diamon/containment references for
> components like attribute groups and model group definitions, how are
> cycles handled? I realize that they are not allowed, but if one is
> encountered, how do I detect this case? Will the isCycle() indicate
> this and if so, does it do so only on references, or would an
> attribute group that has indirect recursion indicate that it is a
> cyclical on the definition?
>
> Thanks,
>
> James
>
> Ed Merks wrote:
>
>> James,
>
>
>> The key here seems to be *how *you are traversing the schema. A
>> black diamond/containment reference cannot reach a detached
>> placeholder, otherwise the placeholder would have a parent/container
>> and would not be detached. So your traversal of the schema must be
>> visiting non-black diamond/non-containment references (which could
>> lead to circularity). Perhaps you are walking directly from a
>> particle to its term rather than from the particle to its particle
>> content; if the particle content is an element reference, the term
>> will be the resolved element declaration, i.e., a placeholder in the
>> case of an element reference that fails to resolve.
>
>
>
>> James Taylor wrote:
>
>
>>> Ed,
>>>
>>> After the schema is loaded, the unresolved element reference is not
>>> any where in the model. It seems that this placeholder has replaced
>>> it. If I fully traverse all terms, none of them statisfy the
>>> isElementDeclarationReference check. However, validate is able to
>>> point out that the element reference is not resolved. Is that
>>> expected? How can I recognize an unresolved element reference when
>>> I'm traversing a schema? Thanks,
>>>
>>> James
>>>
>>> Ed Merks wrote:
>>>
>>>> James,
>>>
>>>
>>>
>>>> An element reference that can't be resolved will result in the
>>>> creation of a detached placeholder that acts as the resolved
>>>> element declaration. It is not considered a reference, since it
>>>> resolves to itself, and is not part of any schema.
>>>
>>>
>>>
>>>> Unresolved element references are diagnosed like this in
>>>> XSDElementDeclarationImpl.validate
>>>
>>>
>>>
>>>> if (isElementDeclarationReference())
>>>> {
>>>> XSDElementDeclaration theResolvedElementDeclaration =
>>>> getResolvedElementDeclaration();
>>>> if (theResolvedElementDeclaration.getContainer() == null)
>>>> {
>>>> createDiagnostic
>>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>>> "_UI_UnresolvedElementDeclaration_message",
>>>> theResolvedElementDeclaration.getURI());
>>>> }
>>>
>>>
>>>
>>>
>>>> James Taylor wrote:
>>>
>>>
>>>
>>>>> If I have a schema that uses an element reference that is invalid
>>>>> (i.e. the file containing the element declaration was mistakenly
>>>>> not included), how can I detect this from the
>>>>> XSDElementDeclaration instance? The instance seems to be in a
>>>>> strange state in which it has no container and is not considered
>>>>> an element reference (i.e.
>>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>>> false). Is this a bug?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> James
>>>>>
>>>
>>>
>
>
--------------090003090607010804080900
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
James,<br>
<br>
These two methods can be used to check for circularity before you even
traverse:<br>
<br>
XSDRedefinableComponent.isCircular:<br>
<blockquote>
|
|
|
| Re: unresolved element ref [message #592394 is a reply to message #54571] |
Sun, 07 November 2004 15:56 |
| Eclipse User |
|
|
|
Ed,
I've modified my traversal to use the black diamon/containment references
and it works well now. However, I have a similar problem when traversing
from a type to its base type. If the base type isn't resolved, then the
type using this base type seems to not be contained by any schema. Is
there a different relationship I should be traversing? Thanks,
James
Ed Merks wrote:
> James,
> These two methods can be used to check for circularity before you even
> traverse:
> XSDRedefinableComponent.isCircular:
> * This indicates whether the definition is circular,
> * e.g., circular base, item, or member types reference,
> * circular attribute group definition reference,
> * or circular model group definition reference.
> XSDElementDeclaration.isCircular:
> * This indicates that the element declaration is part of an invalid
> circular substitution group.
> So yes, you can check for an attribute group being circular. Even
> without circularity, the same model group can be used more than once in
> a content model, so you may want to prevent multiple visits of the same
> object by keeping track of those already been visited....
> James Taylor wrote:
>> Ed,
>>
>> Yes, you are exactly right -- I am walking from a particle directly to
>> its term. If I navigate the black diamon/containment references for
>> components like attribute groups and model group definitions, how are
>> cycles handled? I realize that they are not allowed, but if one is
>> encountered, how do I detect this case? Will the isCycle() indicate
>> this and if so, does it do so only on references, or would an
>> attribute group that has indirect recursion indicate that it is a
>> cyclical on the definition?
>>
>> Thanks,
>>
>> James
>>
>> Ed Merks wrote:
>>
>>> James,
>>
>>
>>> The key here seems to be *how *you are traversing the schema. A
>>> black diamond/containment reference cannot reach a detached
>>> placeholder, otherwise the placeholder would have a parent/container
>>> and would not be detached. So your traversal of the schema must be
>>> visiting non-black diamond/non-containment references (which could
>>> lead to circularity). Perhaps you are walking directly from a
>>> particle to its term rather than from the particle to its particle
>>> content; if the particle content is an element reference, the term
>>> will be the resolved element declaration, i.e., a placeholder in the
>>> case of an element reference that fails to resolve.
>>
>>
>>
>>> James Taylor wrote:
>>
>>
>>>> Ed,
>>>>
>>>> After the schema is loaded, the unresolved element reference is not
>>>> any where in the model. It seems that this placeholder has replaced
>>>> it. If I fully traverse all terms, none of them statisfy the
>>>> isElementDeclarationReference check. However, validate is able to
>>>> point out that the element reference is not resolved. Is that
>>>> expected? How can I recognize an unresolved element reference when
>>>> I'm traversing a schema? Thanks,
>>>>
>>>> James
>>>>
>>>> Ed Merks wrote:
>>>>
>>>>> James,
>>>>
>>>>
>>>>
>>>>> An element reference that can't be resolved will result in the
>>>>> creation of a detached placeholder that acts as the resolved
>>>>> element declaration. It is not considered a reference, since it
>>>>> resolves to itself, and is not part of any schema.
>>>>
>>>>
>>>>
>>>>> Unresolved element references are diagnosed like this in
>>>>> XSDElementDeclarationImpl.validate
>>>>
>>>>
>>>>
>>>>> if (isElementDeclarationReference())
>>>>> {
>>>>> XSDElementDeclaration theResolvedElementDeclaration =
>>>>> getResolvedElementDeclaration();
>>>>> if (theResolvedElementDeclaration.getContainer() == null)
>>>>> {
>>>>> createDiagnostic
>>>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>>>> "_UI_UnresolvedElementDeclaration_message",
>>>>> theResolvedElementDeclaration.getURI());
>>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>> James Taylor wrote:
>>>>
>>>>
>>>>
>>>>>> If I have a schema that uses an element reference that is invalid
>>>>>> (i.e. the file containing the element declaration was mistakenly
>>>>>> not included), how can I detect this from the
>>>>>> XSDElementDeclaration instance? The instance seems to be in a
>>>>>> strange state in which it has no container and is not considered
>>>>>> an element reference (i.e.
>>>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>>>> false). Is this a bug?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> James
>>>>>>
>>>>
>>>>
>>
>>
|
|
|
| Re: unresolved element ref [message #592406 is a reply to message #54595] |
Mon, 08 November 2004 07:06 |
| Eclipse User |
|
|
|
James,
No, it's the place holder representing the unresolved base type itself
that won't be contained by a schema; the type that you reached via black
diamond containment from the schema will be attached and will reference
something that isn't...
James Taylor wrote:
> Ed,
>
> I've modified my traversal to use the black diamon/containment
> references and it works well now. However, I have a similar problem
> when traversing from a type to its base type. If the base type isn't
> resolved, then the type using this base type seems to not be contained
> by any schema. Is there a different relationship I should be
> traversing? Thanks,
>
> James
>
> Ed Merks wrote:
>
>> James,
>
>
>> These two methods can be used to check for circularity before you
>> even traverse:
>
>
>> XSDRedefinableComponent.isCircular:
>
>
>> * This indicates whether the definition is circular,
>> * e.g., circular base, item, or member types reference,
>> * circular attribute group definition reference,
>> * or circular model group definition reference.
>
>
>> XSDElementDeclaration.isCircular:
>
>
>> * This indicates that the element declaration is part of an invalid
>> circular substitution group.
>
>
>> So yes, you can check for an attribute group being circular. Even
>> without circularity, the same model group can be used more than once
>> in a content model, so you may want to prevent multiple visits of the
>> same object by keeping track of those already been visited....
>
>
>
>> James Taylor wrote:
>
>
>>> Ed,
>>>
>>> Yes, you are exactly right -- I am walking from a particle directly
>>> to its term. If I navigate the black diamon/containment references
>>> for components like attribute groups and model group definitions,
>>> how are cycles handled? I realize that they are not allowed, but if
>>> one is encountered, how do I detect this case? Will the isCycle()
>>> indicate this and if so, does it do so only on references, or would
>>> an attribute group that has indirect recursion indicate that it is a
>>> cyclical on the definition?
>>>
>>> Thanks,
>>>
>>> James
>>>
>>> Ed Merks wrote:
>>>
>>>> James,
>>>
>>>
>>>
>>>> The key here seems to be *how *you are traversing the schema. A
>>>> black diamond/containment reference cannot reach a detached
>>>> placeholder, otherwise the placeholder would have a
>>>> parent/container and would not be detached. So your traversal of
>>>> the schema must be visiting non-black diamond/non-containment
>>>> references (which could lead to circularity). Perhaps you are
>>>> walking directly from a particle to its term rather than from the
>>>> particle to its particle content; if the particle content is an
>>>> element reference, the term will be the resolved element
>>>> declaration, i.e., a placeholder in the case of an element
>>>> reference that fails to resolve.
>>>
>>>
>>>
>>>
>>>> James Taylor wrote:
>>>
>>>
>>>
>>>>> Ed,
>>>>>
>>>>> After the schema is loaded, the unresolved element reference is
>>>>> not any where in the model. It seems that this placeholder has
>>>>> replaced it. If I fully traverse all terms, none of them statisfy
>>>>> the isElementDeclarationReference check. However, validate is
>>>>> able to point out that the element reference is not resolved. Is
>>>>> that expected? How can I recognize an unresolved element
>>>>> reference when I'm traversing a schema? Thanks,
>>>>>
>>>>> James
>>>>>
>>>>> Ed Merks wrote:
>>>>>
>>>>>> James,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> An element reference that can't be resolved will result in the
>>>>>> creation of a detached placeholder that acts as the resolved
>>>>>> element declaration. It is not considered a reference, since it
>>>>>> resolves to itself, and is not part of any schema.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Unresolved element references are diagnosed like this in
>>>>>> XSDElementDeclarationImpl.validate
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> if (isElementDeclarationReference())
>>>>>> {
>>>>>> XSDElementDeclaration theResolvedElementDeclaration =
>>>>>> getResolvedElementDeclaration();
>>>>>> if (theResolvedElementDeclaration.getContainer() == null)
>>>>>> {
>>>>>> createDiagnostic
>>>>>> (XSDDiagnosticSeverity.ERROR_LITERAL,
>>>>>> "_UI_UnresolvedElementDeclaration_message",
>>>>>> theResolvedElementDeclaration.getURI());
>>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> James Taylor wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> If I have a schema that uses an element reference that is
>>>>>>> invalid (i.e. the file containing the element declaration was
>>>>>>> mistakenly not included), how can I detect this from the
>>>>>>> XSDElementDeclaration instance? The instance seems to be in a
>>>>>>> strange state in which it has no container and is not considered
>>>>>>> an element reference (i.e.
>>>>>>> XSDElementDeclaration.isElementDeclarationReference() returns
>>>>>>> false). Is this a bug?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
Goto Forum:
Current Time: Tue Nov 04 05:50:53 EST 2025
Powered by FUDForum. Page generated in 0.40919 seconds |
Home