Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » href help
href help [message #34721] Mon, 05 January 2004 16:05 Go to next message
Lance Phillips is currently offline Lance Phillips
Messages: 210
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_0008_01C3D373.848EB2B0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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?

thanks,

lp
------=_NextPart_000_0008_01C3D373.848EB2B0
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>
<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>

------=_NextPart_000_0008_01C3D373.848EB2B0--
Re: href help [message #34790 is a reply to message #34721] Mon, 05 January 2004 16:13 Go to previous messageGo to next message
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.&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>

--------------2B176D09AB83A74AD6AAA274--
Re: href help [message #34824 is a reply to message #34790] Mon, 05 January 2004 16:17 Go to previous messageGo to next message
Lance Phillips is currently offline 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>&nbsp;&nbsp;&nbsp; That is what makes =
this so=20
crazy.... the XSD iteself is unchanged and there is only one root =
entity.&nbsp;=20
We are only seeing is this in one of our meta models.&nbsp; The entities =
in that=20
model reference schema components for validation.&nbsp; The hrefs in=20
the&nbsp;referencing model&nbsp;are the ones that are bad.&nbsp; 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.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>lp</FONT>&nbsp;</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" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=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.&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>

------=_NextPart_000_000C_01C3D375.24A037A0--
Re: href help [message #34858 is a reply to message #34824] Mon, 05 January 2004 18:05 Go to previous message
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>&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>

</body>
</html>

--------------DD47E0BFDBCE07259E5BE336--
Re: href help [message #582115 is a reply to message #34721] Mon, 05 January 2004 16:13 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26088
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.&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>

--------------2B176D09AB83A74AD6AAA274--
Re: href help [message #582150 is a reply to message #34790] Mon, 05 January 2004 16:17 Go to previous message
Lance Phillips is currently offline 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>&nbsp;&nbsp;&nbsp; That is what makes =
this so=20
crazy.... the XSD iteself is unchanged and there is only one root =
entity.&nbsp;=20
We are only seeing is this in one of our meta models.&nbsp; The entities =
in that=20
model reference schema components for validation.&nbsp; The hrefs in=20
the&nbsp;referencing model&nbsp;are the ones that are bad.&nbsp; 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.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>lp</FONT>&nbsp;</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" &lt;<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>&gt;=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.&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>

------=_NextPart_000_000C_01C3D375.24A037A0--
Re: href help [message #582168 is a reply to message #34824] Mon, 05 January 2004 18:05 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26088
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>&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>

</body>
</html>

--------------DD47E0BFDBCE07259E5BE336--
Previous Topic:facets
Next Topic:"fixed" and "default" and "groups"
Goto Forum:
  


Current Time: Wed Oct 01 06:13:40 GMT 2014

Powered by FUDForum. Page generated in 0.09368 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software