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=20
" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3D3/XSDPartic le/XSDModelG=
roup/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. =20

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?

<!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>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>We are having an occasional problem =
with our xsd=20
hrefs that seems to be neither consistently reproducible or easy to =
track=20
down.&nbsp; Occasionally we see hrefs to our xsd components show up as=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>"</FONT><FONT face=3DArial=20
size=3D2> Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3D3/XSDPartic le/X=
SDModelGroup/XSDParticle=3D4/edition;XSDElementDeclaration".&nbsp;=20
Notice the Books.xsd#/1 portion of the href is junk.&nbsp; It should be=20
Books.xsd#// as the xsd resource can only have one root entity, the =
Schema so=20
the index of 1 is always returning a null entity.&nbsp; </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Has anyone seen anything similar to =
this or can=20
anyone point me at a starting point for debugging that could result in =
this kind=20
of href?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>lp</FONT></DIV></BODY></HTML>

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Lance,
<p>I haven't seen this before.&nbsp; 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.&nbsp; 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 ".&nbsp;
Notice the Books.xsd#/1 portion of the href is junk.&nbsp; 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>&nbsp;<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>&nbsp;<font face="Arial"><font size=-1>thanks,</font></font>&nbsp;<font face="Arial"><font size=-1>lp</font></font></blockquote>
</html>

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

<P>I haven't seen this before.&nbsp; 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.&nbsp; 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 ".&nbsp;=20
Notice the Books.xsd#/1 portion of the href is junk.&nbsp; 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>&nbsp;<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>&nbsp;<FONT=20
face=3DArial><FONT size=3D-1>thanks,</FONT></FONT>&nbsp;<FONT =
face=3DArial><FONT=20
size=3D-1>lp</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY ></HTML>

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
>

<!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>&nbsp; protected String getURIFragmentRootSegment(EObject eObject)
<br>&nbsp; {
<br>&nbsp;&nbsp;&nbsp; List contents = getContents();
<br>&nbsp;&nbsp;&nbsp; return contents.size() > 1 ?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integer.toString(getContents().indexOf(eObject))
:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "";
<br>&nbsp; }
<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>&nbsp;
<p>Lance Phillips wrote:
<blockquote TYPE=CITE>&nbsp;<font face="Arial"><font size=-1>Ed,</font></font><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;
That is what makes this so crazy.... the XSD iteself is unchanged and there
is only one root entity.&nbsp; We are only seeing is this in one of our
meta models.&nbsp; The entities in that model reference schema components
for validation.&nbsp; The hrefs in the referencing model are the ones that
are bad.&nbsp; 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>&nbsp;<font face="Arial"><font size=-1>thanks,</font></font>&nbsp;<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" &lt;<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.&nbsp; 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.&nbsp; Occasionally we
see hrefs to our xsd components show up as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".&nbsp;
Notice the Books.xsd#/1 portion of the href is junk.&nbsp; 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>

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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Lance,
<p>I haven't seen this before.&nbsp; 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.&nbsp; 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 ".&nbsp;
Notice the Books.xsd#/1 portion of the href is junk.&nbsp; 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>&nbsp;<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>&nbsp;<font face="Arial"><font size=-1>thanks,</font></font>&nbsp;<font face="Arial"><font size=-1>lp</font></font></blockquote>
</html>

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

<P>I haven't seen this before.&nbsp; 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.&nbsp; 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 ".&nbsp;=20
Notice the Books.xsd#/1 portion of the href is junk.&nbsp; 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>&nbsp;<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>&nbsp;<FONT=20
face=3DArial><FONT size=3D-1>thanks,</FONT></FONT>&nbsp;<FONT =
face=3DArial><FONT=20
size=3D-1>lp</FONT></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY ></HTML>

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
>

<!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>&nbsp; protected String getURIFragmentRootSegment(EObject eObject)
<br>&nbsp; {
<br>&nbsp;&nbsp;&nbsp; List contents = getContents();
<br>&nbsp;&nbsp;&nbsp; return contents.size() > 1 ?
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Integer.toString(getContents().indexOf(eObject))
:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "";
<br>&nbsp; }
<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>&nbsp;
<p>Lance Phillips wrote:
<blockquote TYPE=CITE>&nbsp;<font face="Arial"><font size=-1>Ed,</font></font><font face="Arial"><font size=-1>&nbsp;&nbsp;&nbsp;
That is what makes this so crazy.... the XSD iteself is unchanged and there
is only one root entity.&nbsp; We are only seeing is this in one of our
meta models.&nbsp; The entities in that model reference schema components
for validation.&nbsp; The hrefs in the referencing model are the ones that
are bad.&nbsp; 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>&nbsp;<font face="Arial"><font size=-1>thanks,</font></font>&nbsp;<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" &lt;<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.&nbsp; 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.&nbsp; Occasionally we
see hrefs to our xsd components show up as" Books.xsd#/1/BookFlat;XSDComplexTypeDefinition=3/XSDParticle /XSDModelGroup/XSDParticle=4/edition;XSDElementDeclaration ".&nbsp;
Notice the Books.xsd#/1 portion of the href is junk.&nbsp; 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>