Home » Archived » XML Schema Definition (XSD) » href help
|
| Re: href help [message #34790 is a reply to message #34721] |
Mon, 05 January 2004 16:13   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------2B176D09AB83A74AD6AAA274
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
I haven't seen this before. You could add a listener to the resource to
see when a second root object is added to its contents...
Lance Phillips wrote:
> We are having an occasional problem with our xsd hrefs that seems to
> be neither consistently reproducible or easy to track down.
> Occasionally we see hrefs to our xsd components show up
> as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
> Notice the Books.xsd#/1 portion of the href is junk. It should be
> Books.xsd#// as the xsd resource can only have one root entity, the
> Schema so the index of 1 is always returning a null entity. Has anyone
> seen anything similar to this or can anyone point me at a starting
> point for debugging that could result in this kind of href? thanks, lp
--------------2B176D09AB83A74AD6AAA274
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Lance,
<p>I haven't seen this before. You could add a listener to the resource
to see when a second root object is added to its contents...
<p>Lance Phillips wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>We
are having an occasional problem with our xsd hrefs that seems to be neither
consistently reproducible or easy to track down. Occasionally we
see hrefs to our xsd components show up as</font></font><font face="Arial"><font size=-1>" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
Notice the Books.xsd#/1 portion of the href is junk. It should be
Books.xsd#// as the xsd resource can only have one root entity, the Schema
so the index of 1 is always returning a null entity.</font></font> <font face="Arial"><font size=-1>Has
anyone seen anything similar to this or can anyone point me at a starting
point for debugging that could result in this kind of href?</font></font> <font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font></blockquote>
</html>
--------------2B176D09AB83A74AD6AAA274--
|
|
|
| Re: href help [message #34824 is a reply to message #34790] |
Mon, 05 January 2004 16:17 |
 Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C3D375.24A037A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
That is what makes this so crazy.... the XSD iteself is unchanged =
and there is only one root entity. We are only seeing is this in one of =
our meta models. The entities in that model reference schema components =
for validation. The hrefs in the referencing model are the ones that =
are bad. As I mentioned, we have yet to create anything reproducible =
but we can't write it off as we have seen it mutiple times.=20
thanks,
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3FF98D2E.E0F7E5@ca.ibm.com...
Lance,=20
I haven't seen this before. You could add a listener to the resource =
to see when a second root object is added to its contents...=20
Lance Phillips wrote:=20
We are having an occasional problem with our xsd hrefs that seems to =
be neither consistently reproducible or easy to track down. =
Occasionally we see hrefs to our xsd components show up =
as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3D3/XSDPartic le/XSDMode=
lGroup/XSDParticle=3D4/edition;XSDElementDeclaration". Notice the =
Books.xsd#/1 portion of the href is junk. It should be Books.xsd#// as =
the xsd resource can only have one root entity, the Schema so the index =
of 1 is always returning a null entity. Has anyone seen anything similar =
to this or can anyone point me at a starting point for debugging that =
could result in this kind of href? thanks, lp
------=_NextPart_000_000C_01C3D375.24A037A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> That is what makes =
this so=20
crazy.... the XSD iteself is unchanged and there is only one root =
entity. =20
We are only seeing is this in one of our meta models. The entities =
in that=20
model reference schema components for validation. The hrefs in=20
the referencing model are the ones that are bad. As I =
mentioned,=20
we have yet to create anything reproducible but we can't write it off as =
we have=20
seen it mutiple times. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>lp</FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3FF98D2E.E0F7E5@ca.ibm.com">news:3FF98D2E.E0F7E5@ca.ibm.com<=
/A>...</DIV>Lance,=20
<P>I haven't seen this before. You could add a listener to the =
resource=20
to see when a second root object is added to its contents...=20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>We are having an occasional =
problem with our=20
xsd hrefs that seems to be neither consistently reproducible or easy =
to=20
track down. Occasionally we see hrefs to our xsd components =
show up=20
as</FONT></FONT><FONT face=3DArial><FONT=20
=
size=3D-1>" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3D3/XSDPartic le=
/XSDModelGroup/XSDParticle=3D4/edition;XSDElementDeclaration ". =20
Notice the Books.xsd#/1 portion of the href is junk. It should =
be=20
Books.xsd#// as the xsd resource can only have one root entity, the =
Schema=20
so the index of 1 is always returning a null=20
entity.</FONT></FONT> <FONT face=3DArial><FONT size=3D-1>Has =
anyone seen=20
anything similar to this or can anyone point me at a starting point =
for=20
debugging that could result in this kind of =
href?</FONT></FONT> <FONT=20
face=3DArial><FONT size=3D-1>thanks,</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>lp</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY ></HTML>
------=_NextPart_000_000C_01C3D375.24A037A0--
|
|
|
| Re: href help [message #34858 is a reply to message #34824] |
Mon, 05 January 2004 18:05 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------DD47E0BFDBCE07259E5BE336
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
The first segment of a fragment path is computed like this in
ResourceImpl:
protected String getURIFragmentRootSegment(EObject eObject)
{
List contents = getContents();
return contents.size() > 1 ?
Integer.toString(getContents().indexOf(eObject)) :
"";
}
so if you are getting the value 1, there must be more than one object
and the object in question must have been at index 1...
(I hope someone answers forumn questions while I'm gone for the next two
weeks.)
Lance Phillips wrote:
> Ed, That is what makes this so crazy.... the XSD iteself is
> unchanged and there is only one root entity. We are only seeing is
> this in one of our meta models. The entities in that model reference
> schema components for validation. The hrefs in the referencing model
> are the ones that are bad. As I mentioned, we have yet to create
> anything reproducible but we can't write it off as we have seen it
> mutiple times. thanks, lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3FF98D2E.E0F7E5@ca.ibm.com...Lance,
>
> I haven't seen this before. You could add a listener to the
> resource to see when a second root object is added to its
> contents...
>
> Lance Phillips wrote:
>
> > We are having an occasional problem with our xsd hrefs
> > that seems to be neither consistently reproducible or easy
> > to track down. Occasionally we see hrefs to our xsd
> > components show up
> > as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
> > Notice the Books.xsd#/1 portion of the href is junk. It
> > should be Books.xsd#// as the xsd resource can only have
> > one root entity, the Schema so the index of 1 is always
> > returning a null entity. Has anyone seen anything similar
> > to this or can anyone point me at a starting point for
> > debugging that could result in this kind of href? thanks,
> > lp
>
--------------DD47E0BFDBCE07259E5BE336
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Lance,
<p>The first segment of a fragment path is computed like this in ResourceImpl:
<p> protected String getURIFragmentRootSegment(EObject eObject)
<br> {
<br> List contents = getContents();
<br> return contents.size() > 1 ?
<br> Integer.toString(getContents().indexOf(eObject))
:
<br> "";
<br> }
<p>so if you are getting the value 1, there must be more than one object
and the object in question must have been at index 1...
<p>(I hope someone answers forumn questions while I'm gone for the next
two weeks.)
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Ed,</font></font><font face="Arial"><font size=-1>
That is what makes this so crazy.... the XSD iteself is unchanged and there
is only one root entity. We are only seeing is this in one of our
meta models. The entities in that model reference schema components
for validation. The hrefs in the referencing model are the ones that
are bad. As I mentioned, we have yet to create anything reproducible
but we can't write it off as we have seen it mutiple times.</font></font> <font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font>
<blockquote dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed
Merks" <<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote
in message <a href="news:3FF98D2E.E0F7E5@ca.ibm.com">news:3FF98D2E.E0F7E5@ca.ibm.com</a>...Lance,
<p>I haven't seen this before. You could add a listener to the resource
to see when a second root object is added to its contents...
<p>Lance Phillips wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>We
are having an occasional problem with our xsd hrefs that seems to be neither
consistently reproducible or easy to track down. Occasionally we
see hrefs to our xsd components show up as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
Notice the Books.xsd#/1 portion of the href is junk. It should be
Books.xsd#// as the xsd resource can only have one root entity, the Schema
so the index of 1 is always returning a null entity.</font></font> <font face="Arial"><font size=-1>Has
anyone seen anything similar to this or can anyone point me at a starting
point for debugging that could result in this kind of href?</font></font>
<font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font></blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------DD47E0BFDBCE07259E5BE336--
|
|
|
| Re: href help [message #582115 is a reply to message #34721] |
Mon, 05 January 2004 16:13 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
--------------2B176D09AB83A74AD6AAA274
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
I haven't seen this before. You could add a listener to the resource to
see when a second root object is added to its contents...
Lance Phillips wrote:
> We are having an occasional problem with our xsd hrefs that seems to
> be neither consistently reproducible or easy to track down.
> Occasionally we see hrefs to our xsd components show up
> as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
> Notice the Books.xsd#/1 portion of the href is junk. It should be
> Books.xsd#// as the xsd resource can only have one root entity, the
> Schema so the index of 1 is always returning a null entity. Has anyone
> seen anything similar to this or can anyone point me at a starting
> point for debugging that could result in this kind of href? thanks, lp
--------------2B176D09AB83A74AD6AAA274
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Lance,
<p>I haven't seen this before. You could add a listener to the resource
to see when a second root object is added to its contents...
<p>Lance Phillips wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>We
are having an occasional problem with our xsd hrefs that seems to be neither
consistently reproducible or easy to track down. Occasionally we
see hrefs to our xsd components show up as</font></font><font face="Arial"><font size=-1>" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
Notice the Books.xsd#/1 portion of the href is junk. It should be
Books.xsd#// as the xsd resource can only have one root entity, the Schema
so the index of 1 is always returning a null entity.</font></font> <font face="Arial"><font size=-1>Has
anyone seen anything similar to this or can anyone point me at a starting
point for debugging that could result in this kind of href?</font></font> <font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font></blockquote>
</html>
--------------2B176D09AB83A74AD6AAA274--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: href help [message #582150 is a reply to message #34790] |
Mon, 05 January 2004 16:17 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C3D375.24A037A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
That is what makes this so crazy.... the XSD iteself is unchanged =
and there is only one root entity. We are only seeing is this in one of =
our meta models. The entities in that model reference schema components =
for validation. The hrefs in the referencing model are the ones that =
are bad. As I mentioned, we have yet to create anything reproducible =
but we can't write it off as we have seen it mutiple times.=20
thanks,
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3FF98D2E.E0F7E5@ca.ibm.com...
Lance,=20
I haven't seen this before. You could add a listener to the resource =
to see when a second root object is added to its contents...=20
Lance Phillips wrote:=20
We are having an occasional problem with our xsd hrefs that seems to =
be neither consistently reproducible or easy to track down. =
Occasionally we see hrefs to our xsd components show up =
as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3D3/XSDPartic le/XSDMode=
lGroup/XSDParticle=3D4/edition;XSDElementDeclaration". Notice the =
Books.xsd#/1 portion of the href is junk. It should be Books.xsd#// as =
the xsd resource can only have one root entity, the Schema so the index =
of 1 is always returning a null entity. Has anyone seen anything similar =
to this or can anyone point me at a starting point for debugging that =
could result in this kind of href? thanks, lp
------=_NextPart_000_000C_01C3D375.24A037A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> That is what makes =
this so=20
crazy.... the XSD iteself is unchanged and there is only one root =
entity. =20
We are only seeing is this in one of our meta models. The entities =
in that=20
model reference schema components for validation. The hrefs in=20
the referencing model are the ones that are bad. As I =
mentioned,=20
we have yet to create anything reproducible but we can't write it off as =
we have=20
seen it mutiple times. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>lp</FONT> </DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3FF98D2E.E0F7E5@ca.ibm.com">news:3FF98D2E.E0F7E5@ca.ibm.com<=
/A>...</DIV>Lance,=20
<P>I haven't seen this before. You could add a listener to the =
resource=20
to see when a second root object is added to its contents...=20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>We are having an occasional =
problem with our=20
xsd hrefs that seems to be neither consistently reproducible or easy =
to=20
track down. Occasionally we see hrefs to our xsd components =
show up=20
as</FONT></FONT><FONT face=3DArial><FONT=20
=
size=3D-1>" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3D3/XSDPartic le=
/XSDModelGroup/XSDParticle=3D4/edition;XSDElementDeclaration ". =20
Notice the Books.xsd#/1 portion of the href is junk. It should =
be=20
Books.xsd#// as the xsd resource can only have one root entity, the =
Schema=20
so the index of 1 is always returning a null=20
entity.</FONT></FONT> <FONT face=3DArial><FONT size=3D-1>Has =
anyone seen=20
anything similar to this or can anyone point me at a starting point =
for=20
debugging that could result in this kind of =
href?</FONT></FONT> <FONT=20
face=3DArial><FONT size=3D-1>thanks,</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>lp</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY ></HTML>
------=_NextPart_000_000C_01C3D375.24A037A0--
|
|
|
| Re: href help [message #582168 is a reply to message #34824] |
Mon, 05 January 2004 18:05 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
--------------DD47E0BFDBCE07259E5BE336
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
The first segment of a fragment path is computed like this in
ResourceImpl:
protected String getURIFragmentRootSegment(EObject eObject)
{
List contents = getContents();
return contents.size() > 1 ?
Integer.toString(getContents().indexOf(eObject)) :
"";
}
so if you are getting the value 1, there must be more than one object
and the object in question must have been at index 1...
(I hope someone answers forumn questions while I'm gone for the next two
weeks.)
Lance Phillips wrote:
> Ed, That is what makes this so crazy.... the XSD iteself is
> unchanged and there is only one root entity. We are only seeing is
> this in one of our meta models. The entities in that model reference
> schema components for validation. The hrefs in the referencing model
> are the ones that are bad. As I mentioned, we have yet to create
> anything reproducible but we can't write it off as we have seen it
> mutiple times. thanks, lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3FF98D2E.E0F7E5@ca.ibm.com...Lance,
>
> I haven't seen this before. You could add a listener to the
> resource to see when a second root object is added to its
> contents...
>
> Lance Phillips wrote:
>
> > We are having an occasional problem with our xsd hrefs
> > that seems to be neither consistently reproducible or easy
> > to track down. Occasionally we see hrefs to our xsd
> > components show up
> > as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
> > Notice the Books.xsd#/1 portion of the href is junk. It
> > should be Books.xsd#// as the xsd resource can only have
> > one root entity, the Schema so the index of 1 is always
> > returning a null entity. Has anyone seen anything similar
> > to this or can anyone point me at a starting point for
> > debugging that could result in this kind of href? thanks,
> > lp
>
--------------DD47E0BFDBCE07259E5BE336
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body bgcolor="#FFFFFF">
Lance,
<p>The first segment of a fragment path is computed like this in ResourceImpl:
<p> protected String getURIFragmentRootSegment(EObject eObject)
<br> {
<br> List contents = getContents();
<br> return contents.size() > 1 ?
<br> Integer.toString(getContents().indexOf(eObject))
:
<br> "";
<br> }
<p>so if you are getting the value 1, there must be more than one object
and the object in question must have been at index 1...
<p>(I hope someone answers forumn questions while I'm gone for the next
two weeks.)
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Ed,</font></font><font face="Arial"><font size=-1>
That is what makes this so crazy.... the XSD iteself is unchanged and there
is only one root entity. We are only seeing is this in one of our
meta models. The entities in that model reference schema components
for validation. The hrefs in the referencing model are the ones that
are bad. As I mentioned, we have yet to create anything reproducible
but we can't write it off as we have seen it mutiple times.</font></font> <font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font>
<blockquote dir=ltr
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed
Merks" <<a href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote
in message <a href="news:3FF98D2E.E0F7E5@ca.ibm.com">news:3FF98D2E.E0F7E5@ca.ibm.com</a>...Lance,
<p>I haven't seen this before. You could add a listener to the resource
to see when a second root object is added to its contents...
<p>Lance Phillips wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>We
are having an occasional problem with our xsd hrefs that seems to be neither
consistently reproducible or easy to track down. Occasionally we
see hrefs to our xsd components show up as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".
Notice the Books.xsd#/1 portion of the href is junk. It should be
Books.xsd#// as the xsd resource can only have one root entity, the Schema
so the index of 1 is always returning a null entity.</font></font> <font face="Arial"><font size=-1>Has
anyone seen anything similar to this or can anyone point me at a starting
point for debugging that could result in this kind of href?</font></font>
<font face="Arial"><font size=-1>thanks,</font></font> <font face="Arial"><font size=-1>lp</font></font></blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------DD47E0BFDBCE07259E5BE336--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 09:55:53 GMT 2024
Powered by FUDForum. Page generated in 0.03537 seconds |
] 
Search
Help
Register
Login
Home
