Home » Archived » XML Schema Definition (XSD) » Help with reader adapter extension
|
| Re: Help with reader adapter extension [message #30916 is a reply to message #30880] |
Tue, 30 September 2003 20:52   |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Lance,
Maybe your aren't adding to, or setting, the black diamond containment
relations, e.g., XSDSchema.getContents()? Have you look in the Javadoc at how
XSDPrototypicalSchema builds various constructs from scratch. You'll need to do
essentially this same kind of thing, but on the fly. Avoid setting values whose
Javadoc says "It is computed from *blah* and should typically not be set
directly." Note that the resolveXyz methods are useful to create placeholders
that can be used in a reference before the referent is created, e.g., the type
of an element where the type is defined later in the schema.
Lance Phillips wrote:
> All,
> I'm working on an xmi reader adapter implementation that can read legacy
> models we have that represent our old approach to xsd. What the reader does
> is interpret what Eclipse XSD element / attribute to create in place of our
> old xsd implementation. I'm running into problems with Attributes and both
> Complex / Simple Types (I'm sure others as I get farther). The problem is
> that when I run into an Attribute representation from our legacy model, I
> use the XSDFactory.eInstance to create a new XSDAttribute. However, I am
> unable to add the Attribute to it's parent (XSDSchema, XSDElement or
> XSDComplexType). What steps am I missing to add Attributes, Types and
> Groups to their parent when processing in an xmi reader adapter
> implementation? It seems to be missing type information that I don't have
> yet as I do not get any of the features for the new entity until I've
> already had to create the entity and add it to a parent. I have also tried
> using the resolveXXX methods on XSDConcreteComponentImpl to no avail.
>
> HELP!!
>
> thanks,
>
> lp
|
|
|
| Re: Help with reader adapter extension [message #30951 is a reply to message #30916] |
Wed, 01 October 2003 14:46 |
 Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
Thanks Ed... looks like I can find most everything I need there. In
addition, I found a better example on how to do the Annotations for
SimpleTypes from my post below. It seems to be working... however, when I
write the contents of the resource out via a save, the text node under the
documentation is not being written out???? Known bug, or am I still missing
something?
thanks,
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3F79ECF4.E966FBB3@ca.ibm.com...
> Lance,
>
> Maybe your aren't adding to, or setting, the black diamond containment
> relations, e.g., XSDSchema.getContents()? Have you look in the Javadoc at
how
> XSDPrototypicalSchema builds various constructs from scratch. You'll need
to do
> essentially this same kind of thing, but on the fly. Avoid setting values
whose
> Javadoc says "It is computed from *blah* and should typically not be set
> directly." Note that the resolveXyz methods are useful to create
placeholders
> that can be used in a reference before the referent is created, e.g., the
type
> of an element where the type is defined later in the schema.
>
>
> Lance Phillips wrote:
>
> > All,
> > I'm working on an xmi reader adapter implementation that can read
legacy
> > models we have that represent our old approach to xsd. What the reader
does
> > is interpret what Eclipse XSD element / attribute to create in place of
our
> > old xsd implementation. I'm running into problems with Attributes and
both
> > Complex / Simple Types (I'm sure others as I get farther). The problem
is
> > that when I run into an Attribute representation from our legacy model,
I
> > use the XSDFactory.eInstance to create a new XSDAttribute. However, I
am
> > unable to add the Attribute to it's parent (XSDSchema, XSDElement or
> > XSDComplexType). What steps am I missing to add Attributes, Types and
> > Groups to their parent when processing in an xmi reader adapter
> > implementation? It seems to be missing type information that I don't
have
> > yet as I do not get any of the features for the new entity until I've
> > already had to create the entity and add it to a parent. I have also
tried
> > using the resolveXXX methods on XSDConcreteComponentImpl to no avail.
> >
> > HELP!!
> >
> > thanks,
> >
> > lp
>
|
|
|
| Re: Help with reader adapter extension [message #30986 is a reply to message #30951] |
Wed, 01 October 2003 15:27 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------93C0315AA641E479F1D76F1C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
It seems that you must still be missing something. A save on an XSD model is
essentially just using DOM serialization:
protected void doSave(OutputStream os, Map options) throws
IOException
{
XSDSchema xsdSchema = getSchema();
if (xsdSchema != null)
{
Document document = xsdSchema.getDocument();
if (document == null)
{
xsdSchema.updateDocument();
document = xsdSchema.getDocument();
}
if (xsdSchema.getElement() == null)
{
xsdSchema.updateElement();
}
doSerialize(os, document, options == null ? null :
(String)options.get(XSD_ENCODING));
}
}
So if you've built the DOM correctly it should be fine. Trying printing out the
DOM Elements as you modify them using XSDResourceImpl.serialize to see if they
look as you expect. Note that the prototypical schema example produces this
correctly:
<xsd:complexType abstract="false" block="#all" final="#all"
mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<xsd:annotation>
<xsd:appinfo source="http://www.example.com/appinfo"/>
<xsd:documentation
source="http://www.example.com/documentation">A simple
recursive complex type definition.</xsd:documentation>
</xsd:annotation>
so if you do it right, it should work...
Lance Phillips wrote:
> Thanks Ed... looks like I can find most everything I need there. In
> addition, I found a better example on how to do the Annotations for
> SimpleTypes from my post below. It seems to be working... however, when I
> write the contents of the resource out via a save, the text node under the
> documentation is not being written out???? Known bug, or am I still missing
> something?
>
> thanks,
>
> lp
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F79ECF4.E966FBB3@ca.ibm.com...
> > Lance,
> >
> > Maybe your aren't adding to, or setting, the black diamond containment
> > relations, e.g., XSDSchema.getContents()? Have you look in the Javadoc at
> how
> > XSDPrototypicalSchema builds various constructs from scratch. You'll need
> to do
> > essentially this same kind of thing, but on the fly. Avoid setting values
> whose
> > Javadoc says "It is computed from *blah* and should typically not be set
> > directly." Note that the resolveXyz methods are useful to create
> placeholders
> > that can be used in a reference before the referent is created, e.g., the
> type
> > of an element where the type is defined later in the schema.
> >
> >
> > Lance Phillips wrote:
> >
> > > All,
> > > I'm working on an xmi reader adapter implementation that can read
> legacy
> > > models we have that represent our old approach to xsd. What the reader
> does
> > > is interpret what Eclipse XSD element / attribute to create in place of
> our
> > > old xsd implementation. I'm running into problems with Attributes and
> both
> > > Complex / Simple Types (I'm sure others as I get farther). The problem
> is
> > > that when I run into an Attribute representation from our legacy model,
> I
> > > use the XSDFactory.eInstance to create a new XSDAttribute. However, I
> am
> > > unable to add the Attribute to it's parent (XSDSchema, XSDElement or
> > > XSDComplexType). What steps am I missing to add Attributes, Types and
> > > Groups to their parent when processing in an xmi reader adapter
> > > implementation? It seems to be missing type information that I don't
> have
> > > yet as I do not get any of the features for the new entity until I've
> > > already had to create the entity and add it to a parent. I have also
> tried
> > > using the resolveXXX methods on XSDConcreteComponentImpl to no avail.
> > >
> > > HELP!!
> > >
> > > thanks,
> > >
> > > lp
> >
--------------93C0315AA641E479F1D76F1C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt><tt></tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt><tt></tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<A HREF="http://www.example.com/appinfo"/">http://www.example.com/appinfo"/</A>>
<br>
<xsd:documentation
<br>
source="<A HREF="http://www.example.com/documentation">http://www.example.com/documentation</A>"><b>A simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE>Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</html>
--------------93C0315AA641E479F1D76F1C--
|
|
|
| Re: Help with reader adapter extension [message #31019 is a reply to message #30986] |
Wed, 01 October 2003 15:42 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C38808.B8FFE5C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I can't figure out what I'm missing... I cut and pasted the code from =
the Prototype. The ONLY thing I'm doing differently is that I am not =
setting the source URI. Is that required?
When I process my model after everything is built, I get an Annotation =
that has a UserInfo EList, the data attribute of that EList contains a =
ElementNSInfo node who's first child is a Text node containing my text. =
Seems correct??? But it does not get written out.
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF274.93480F89@ca.ibm.com...
Lance,=20
It seems that you must still be missing something. A save on an XSD =
model is essentially just using DOM serialization:=20
protected void doSave(OutputStream os, Map options) throws =
IOException=20
{=20
XSDSchema xsdSchema =3D getSchema();=20
if (xsdSchema !=3D null)=20
{=20
Document document =3D xsdSchema.getDocument();=20
if (document =3D=3D null)=20
{=20
xsdSchema.updateDocument();=20
document =3D xsdSchema.getDocument();=20
}=20
if (xsdSchema.getElement() =3D=3D null)=20
{=20
xsdSchema.updateElement();=20
}=20
doSerialize(os, document, options =3D=3D null ? null : =
(String)options.get(XSD_ENCODING));=20
}=20
}
So if you've built the DOM correctly it should be fine. Trying =
printing out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to see if they look as you expect. Note that =
the prototypical schema example produces this correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" final=3D"#all"=20
mixed=3D"true" name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo source=3D"http://www.example.com/appinfo"/>=20
<xsd:documentation=20
source=3D"http://www.example.com/documentation">A =
simple=20
recursive complex type definition.</xsd:documentation> =
</xsd:annotation>=20
so if you do it right, it should work...=20
=20
Lance Phillips wrote:=20
Thanks Ed... looks like I can find most everything I need there. In =
addition, I found a better example on how to do the Annotations for=20
SimpleTypes from my post below. It seems to be working... however, =
when I=20
write the contents of the resource out via a save, the text node =
under the=20
documentation is not being written out???? Known bug, or am I still =
missing=20
something?=20
thanks,=20
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:3F79ECF4.E966FBB3@ca.ibm.com...=20
> Lance,=20
>=20
> Maybe your aren't adding to, or setting, the black diamond =
containment=20
> relations, e.g., XSDSchema.getContents()? Have you look in the =
Javadoc at=20
how=20
> XSDPrototypicalSchema builds various constructs from scratch. =
You'll need=20
to do=20
> essentially this same kind of thing, but on the fly. Avoid =
setting values=20
whose=20
> Javadoc says "It is computed from *blah* and should typically not =
be set=20
> directly." Note that the resolveXyz methods are useful to create=20
placeholders=20
> that can be used in a reference before the referent is created, =
e.g., the=20
type=20
> of an element where the type is defined later in the schema.=20
>=20
>=20
> Lance Phillips wrote:=20
>=20
> > All,=20
> > I'm working on an xmi reader adapter implementation that can =
read=20
legacy=20
> > models we have that represent our old approach to xsd. What the =
reader=20
does=20
> > is interpret what Eclipse XSD element / attribute to create in =
place of=20
our=20
> > old xsd implementation. I'm running into problems with =
Attributes and=20
both=20
> > Complex / Simple Types (I'm sure others as I get farther). The =
problem=20
is=20
> > that when I run into an Attribute representation from our legacy =
model,=20
I=20
> > use the XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
am=20
> > unable to add the Attribute to it's parent (XSDSchema, =
XSDElement or=20
> > XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
> > Groups to their parent when processing in an xmi reader adapter=20
> > implementation? It seems to be missing type information that I =
don't=20
have=20
> > yet as I do not get any of the features for the new entity until =
I've=20
> > already had to create the entity and add it to a parent. I have =
also=20
tried=20
> > using the resolveXXX methods on XSDConcreteComponentImpl to no =
avail.=20
> >=20
> > HELP!!=20
> >=20
> > thanks,=20
> >=20
> > lp=20
>
------=_NextPart_000_0016_01C38808.B8FFE5C0
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.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I can't figure out what I'm missing... =
I cut and=20
pasted the code from the Prototype. The ONLY thing I'm doing =
differently=20
is that I am not setting the source URI. Is that =
required?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>When I process my model after =
everything is built,=20
I get an Annotation that has a UserInfo EList, the data attribute of =
that EList=20
contains a ElementNSInfo node who's first child is a Text node =
containing my=20
text. Seems correct??? But it does not get written =
out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.=
com</A>...</DIV>Lance,=20
<P>It seems that you must still be missing something. A save on =
an XSD=20
model is essentially just using DOM serialization:=20
<BLOCKQUOTE><TT> protected void doSave(OutputStream os, Map =
options)=20
throws IOException</TT> <BR><TT> {</TT> =
<BR><TT> =20
XSDSchema xsdSchema =3D getSchema();</TT> <BR><TT> =
if=20
(xsdSchema !=3D null)</TT> <BR><TT> {</TT>=20
<BR><TT> Document document =3D=20
xsdSchema.getDocument();</TT> <BR><TT> =
if=20
(document =3D=3D null)</TT> <BR><TT> =
{</TT>=20
<BR><TT> =20
xsdSchema.updateDocument();</TT>=20
<BR><TT> document =3D=20
xsdSchema.getDocument();</TT> <BR><TT> =
}</TT><TT></TT>=20
<P><TT> if (xsdSchema.getElement() =
=3D=3D=20
null)</TT> <BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateElement();</TT> =
<BR><TT> =20
}</TT><TT></TT>=20
<P><TT> doSerialize(os, document, =
options =3D=3D=20
null ? null : (String)options.get(XSD_ENCODING));</TT>=20
<BR><TT> }</TT> <BR><TT> =
}</TT></P></BLOCKQUOTE>So if=20
you've built the DOM correctly it should be fine. Trying =
printing out=20
the DOM Elements as you modify them using XSDResourceImpl.serialize to =
see if=20
they look as you expect. Note that the prototypical schema =
example=20
produces <B>this</B> correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> <xsd:annotation>=20
<BR> =
<xsd:appinfo source=3D"<A href=3D"http://www.example.com/appinfo"=20
?>http://www.example.com/appinfo"/</A>>=20
<BR> =
<xsd:documentation=20
=
<BR> &nb=
sp; =20
source=3D"<A=20
=
href=3D"http://www.example.com/documentation">http://www.example.com/docu=
mentation</A>"><B>A=20
simple</B>=20
=
<BR><B> =
=20
recursive complex type definition.</B></xsd:documentation>=20
<BR> </xsd:annotation> =
<P>so if you do it right, it should work... <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">Thanks Ed... looks like I can find most =
everything I=20
need there. In <BR>addition, I found a better example on how =
to do the=20
Annotations for <BR>SimpleTypes from my post below. It seems =
to be=20
working... however, when I <BR>write the contents of the resource =
out via a=20
save, the text node under the <BR>documentation is not being written =
out???? Known bug, or am I still missing <BR>something?=20
<P>thanks,=20
<P>lp <BR>"Ed Merks" <merks@ca.ibm.com> wrote in message =
<BR><A=20
=
href=3D"news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.=
com</A>...=20
<BR>> Lance, <BR>> <BR>> Maybe your aren't adding to, or =
setting,=20
the black diamond containment <BR>> relations, e.g.,=20
XSDSchema.getContents()? Have you look in the Javadoc at =
<BR>how=20
<BR>> XSDPrototypicalSchema builds various constructs from =
scratch. =20
You'll need <BR>to do <BR>> essentially this same kind of thing, =
but on=20
the fly. Avoid setting values <BR>whose <BR>> Javadoc says =
"It is=20
computed from *blah* and should typically not be set <BR>>=20
directly." Note that the resolveXyz methods are useful to =
create=20
<BR>placeholders <BR>> that can be used in a reference before the =
referent is created, e.g., the <BR>type <BR>> of an element where =
the=20
type is defined later in the schema. <BR>> <BR>> <BR>> =
Lance=20
Phillips wrote: <BR>> <BR>> > All, <BR>>=20
> I'm working on an xmi reader adapter=20
implementation that can read <BR>legacy <BR>> > models we have =
that=20
represent our old approach to xsd. What the reader <BR>does =
<BR>>=20
> is interpret what Eclipse XSD element / attribute to create in =
place of=20
<BR>our <BR>> > old xsd implementation. I'm running into =
problems with Attributes and <BR>both <BR>> > Complex / Simple =
Types=20
(I'm sure others as I get farther). The problem <BR>is =
<BR>> >=20
that when I run into an Attribute representation from our legacy =
model,=20
<BR>I <BR>> > use the XSDFactory.eInstance to create a new=20
XSDAttribute. However, I <BR>am <BR>> > unable to add =
the=20
Attribute to it's parent (XSDSchema, XSDElement or <BR>> >=20
XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
<BR>> > Groups to their parent when processing in an xmi =
reader=20
adapter <BR>> > implementation? It seems to be missing =
type=20
information that I don't <BR>have <BR>> > yet as I do not get =
any of=20
the features for the new entity until I've <BR>> > already had =
to=20
create the entity and add it to a parent. I have also =
<BR>tried=20
<BR>> > using the resolveXXX methods on =
XSDConcreteComponentImpl to no=20
avail. <BR>> > <BR>> > HELP!! <BR>> > <BR>> =
>=20
thanks, <BR>> > <BR>> > lp=20
<BR>></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_0016_01C38808.B8FFE5C0--
|
|
|
| Re: Help with reader adapter extension [message #31060 is a reply to message #31019] |
Wed, 01 October 2003 15:50 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0022_01C38809.CDA176A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
One other important distinction.... I'm adding this annotation as a =
child of a XsdSimpleTypeDefinition. In the documentation in the =
PrototypeSchema it says that the annotation must be attached to a =
schema, does that mean as an immediate child, or simply that it must be =
added to a model?
thanks,
lp
"Lance Phillips" <lphillips@metamatrix.com> wrote in message =
news:blesil$lfn$1@eclipse.org...
I can't figure out what I'm missing... I cut and pasted the code from =
the Prototype. The ONLY thing I'm doing differently is that I am not =
setting the source URI. Is that required?
When I process my model after everything is built, I get an Annotation =
that has a UserInfo EList, the data attribute of that EList contains a =
ElementNSInfo node who's first child is a Text node containing my text. =
Seems correct??? But it does not get written out.
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF274.93480F89@ca.ibm.com...
Lance,=20
It seems that you must still be missing something. A save on an XSD =
model is essentially just using DOM serialization:=20
protected void doSave(OutputStream os, Map options) throws =
IOException=20
{=20
XSDSchema xsdSchema =3D getSchema();=20
if (xsdSchema !=3D null)=20
{=20
Document document =3D xsdSchema.getDocument();=20
if (document =3D=3D null)=20
{=20
xsdSchema.updateDocument();=20
document =3D xsdSchema.getDocument();=20
}=20
if (xsdSchema.getElement() =3D=3D null)=20
{=20
xsdSchema.updateElement();=20
}=20
doSerialize(os, document, options =3D=3D null ? null : =
(String)options.get(XSD_ENCODING));=20
}=20
}
So if you've built the DOM correctly it should be fine. Trying =
printing out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to see if they look as you expect. Note that =
the prototypical schema example produces this correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" =
final=3D"#all"=20
mixed=3D"true" =
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo source=3D"http://www.example.com/appinfo"/> =
<xsd:documentation=20
source=3D"http://www.example.com/documentation">A =
simple=20
recursive complex type =
definition.</xsd:documentation>=20
</xsd:annotation>=20
so if you do it right, it should work...=20
=20
Lance Phillips wrote:=20
Thanks Ed... looks like I can find most everything I need there. =
In=20
addition, I found a better example on how to do the Annotations =
for=20
SimpleTypes from my post below. It seems to be working... =
however, when I=20
write the contents of the resource out via a save, the text node =
under the=20
documentation is not being written out???? Known bug, or am I =
still missing=20
something?=20
thanks,=20
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:3F79ECF4.E966FBB3@ca.ibm.com...=20
> Lance,=20
>=20
> Maybe your aren't adding to, or setting, the black diamond =
containment=20
> relations, e.g., XSDSchema.getContents()? Have you look in the =
Javadoc at=20
how=20
> XSDPrototypicalSchema builds various constructs from scratch. =
You'll need=20
to do=20
> essentially this same kind of thing, but on the fly. Avoid =
setting values=20
whose=20
> Javadoc says "It is computed from *blah* and should typically =
not be set=20
> directly." Note that the resolveXyz methods are useful to =
create=20
placeholders=20
> that can be used in a reference before the referent is created, =
e.g., the=20
type=20
> of an element where the type is defined later in the schema.=20
>=20
>=20
> Lance Phillips wrote:=20
>=20
> > All,=20
> > I'm working on an xmi reader adapter implementation that =
can read=20
legacy=20
> > models we have that represent our old approach to xsd. What =
the reader=20
does=20
> > is interpret what Eclipse XSD element / attribute to create in =
place of=20
our=20
> > old xsd implementation. I'm running into problems with =
Attributes and=20
both=20
> > Complex / Simple Types (I'm sure others as I get farther). =
The problem=20
is=20
> > that when I run into an Attribute representation from our =
legacy model,=20
I=20
> > use the XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
am=20
> > unable to add the Attribute to it's parent (XSDSchema, =
XSDElement or=20
> > XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
> > Groups to their parent when processing in an xmi reader =
adapter=20
> > implementation? It seems to be missing type information that =
I don't=20
have=20
> > yet as I do not get any of the features for the new entity =
until I've=20
> > already had to create the entity and add it to a parent. I =
have also=20
tried=20
> > using the resolveXXX methods on XSDConcreteComponentImpl to no =
avail.=20
> >=20
> > HELP!!=20
> >=20
> > thanks,=20
> >=20
> > lp=20
>
------=_NextPart_000_0022_01C38809.CDA176A0
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.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>One other important distinction.... I'm =
adding this=20
annotation as a child of a XsdSimpleTypeDefinition. In the =
documentation=20
in the PrototypeSchema it says that the annotation must be attached to a =
schema,=20
does that mean as an immediate child, or simply that it must be added to =
a=20
model?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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>"Lance Phillips" <<A=20
=
href=3D"mailto:lphillips@metamatrix.com">lphillips@metamatrix.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:blesil$lfn$1@eclipse.org">news:blesil$lfn$1@eclipse.org</A>.=
...</DIV>
<DIV><FONT face=3DArial size=3D2>I can't figure out what I'm =
missing... I cut and=20
pasted the code from the Prototype. The ONLY thing I'm doing =
differently=20
is that I am not setting the source URI. Is that =
required?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>When I process my model after =
everything is=20
built, I get an Annotation that has a UserInfo EList, the data =
attribute of=20
that EList contains a ElementNSInfo node who's first child is a Text =
node=20
containing my text. Seems correct??? But it does not get =
written=20
out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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=20
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.=
com</A>...</DIV>Lance,=20
<P>It seems that you must still be missing something. A save =
on an XSD=20
model is essentially just using DOM serialization:=20
<BLOCKQUOTE><TT> protected void doSave(OutputStream os, Map =
options)=20
throws IOException</TT> <BR><TT> {</TT> =
<BR><TT> =20
XSDSchema xsdSchema =3D getSchema();</TT> =
<BR><TT> if=20
(xsdSchema !=3D null)</TT> <BR><TT> {</TT>=20
<BR><TT> Document document =3D=20
xsdSchema.getDocument();</TT> =
<BR><TT> if=20
(document =3D=3D null)</TT> <BR><TT> =
{</TT>=20
<BR><TT> =20
xsdSchema.updateDocument();</TT>=20
<BR><TT> document =3D=20
xsdSchema.getDocument();</TT> =
<BR><TT> =20
}</TT><TT></TT>=20
<P><TT> if (xsdSchema.getElement() =
=3D=3D=20
null)</TT> <BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateElement();</TT> =
<BR><TT> =20
}</TT><TT></TT>=20
<P><TT> doSerialize(os, document, =
options =3D=3D=20
null ? null : (String)options.get(XSD_ENCODING));</TT>=20
<BR><TT> }</TT> <BR><TT> =
}</TT></P></BLOCKQUOTE>So=20
if you've built the DOM correctly it should be fine. Trying =
printing=20
out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to=20
see if they look as you expect. Note that the prototypical =
schema=20
example produces <B>this</B> correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> =
<xsd:annotation>=20
=
<BR> =20
<xsd:appinfo source=3D"<A href=3D"http://www.example.com/appinfo" =
?>http://www.example.com/appinfo"/</A>>=20
=
<BR> =20
<xsd:documentation=20
=
<BR> &nb=
sp; =20
source=3D"<A=20
=
href=3D"http://www.example.com/documentation">http://www.example.com/docu=
mentation</A>"><B>A=20
simple</B>=20
=
<BR><B> =
=20
recursive complex type definition.</B></xsd:documentation>=20
<BR> =
</xsd:annotation>=20
<P>so if you do it right, it should work... <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">Thanks Ed... looks like I can find most =
everything=20
I need there. In <BR>addition, I found a better example on =
how to do=20
the Annotations for <BR>SimpleTypes from my post below. It =
seems to=20
be working... however, when I <BR>write the contents of the =
resource out=20
via a save, the text node under the <BR>documentation is not being =
written=20
out???? Known bug, or am I still missing <BR>something?=20
<P>thanks,=20
<P>lp <BR>"Ed Merks" <merks@ca.ibm.com> wrote in message =
<BR><A=20
=
href=3D"news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.=
com</A>...=20
<BR>> Lance, <BR>> <BR>> Maybe your aren't adding to, or =
setting,=20
the black diamond containment <BR>> relations, e.g.,=20
XSDSchema.getContents()? Have you look in the Javadoc at =
<BR>how=20
<BR>> XSDPrototypicalSchema builds various constructs from=20
scratch. You'll need <BR>to do <BR>> essentially this =
same kind=20
of thing, but on the fly. Avoid setting values <BR>whose =
<BR>>=20
Javadoc says "It is computed from *blah* and should typically not =
be set=20
<BR>> directly." Note that the resolveXyz methods are =
useful to=20
create <BR>placeholders <BR>> that can be used in a reference =
before=20
the referent is created, e.g., the <BR>type <BR>> of an element =
where=20
the type is defined later in the schema. <BR>> <BR>> =
<BR>> Lance=20
Phillips wrote: <BR>> <BR>> > All, <BR>>=20
> I'm working on an xmi reader adapter=20
implementation that can read <BR>legacy <BR>> > models we =
have that=20
represent our old approach to xsd. What the reader <BR>does =
<BR>>=20
> is interpret what Eclipse XSD element / attribute to create =
in place=20
of <BR>our <BR>> > old xsd implementation. I'm running =
into=20
problems with Attributes and <BR>both <BR>> > Complex / =
Simple Types=20
(I'm sure others as I get farther). The problem <BR>is =
<BR>> >=20
that when I run into an Attribute representation from our legacy =
model,=20
<BR>I <BR>> > use the XSDFactory.eInstance to create a new=20
XSDAttribute. However, I <BR>am <BR>> > unable to add =
the=20
Attribute to it's parent (XSDSchema, XSDElement or <BR>> >=20
XSDComplexType). What steps am I missing to add Attributes, =
Types=20
and <BR>> > Groups to their parent when processing in an xmi =
reader=20
adapter <BR>> > implementation? It seems to be missing =
type=20
information that I don't <BR>have <BR>> > yet as I do not =
get any of=20
the features for the new entity until I've <BR>> > already =
had to=20
create the entity and add it to a parent. I have also =
<BR>tried=20
<BR>> > using the resolveXXX methods on =
XSDConcreteComponentImpl to=20
no avail. <BR>> > <BR>> > HELP!! <BR>> > =
<BR>> >=20
thanks, <BR>> > <BR>> > lp=20
<BR>></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_0022_01C38809.CDA176A0--
|
|
|
| Re: Help with reader adapter extension [message #31094 is a reply to message #31019] |
Wed, 01 October 2003 15:56 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------8EFEB04FED663851883D96E8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
If I use null as the source URI in the prototype example, it still
prints correctly:
<xsd:complexType abstract="false" block="#all" final="#all"
mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<xsd:annotation>
<xsd:appinfo/>
<xsd:documentation>A simple recursive complex type
definition.</xsd:documen
</xsd:annotation>
<xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<xsd:anyAttribute namespace="##other"/>
</xsd:complexType>
Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
Lance Phillips wrote:
> I can't figure out what I'm missing... I cut and pasted the code from
> the Prototype. The ONLY thing I'm doing differently is that I am not
> setting the source URI. Is that required? When I process my model
> after everything is built, I get an Annotation that has a UserInfo
> EList, the data attribute of that EList contains a ElementNSInfo node
> who's first child is a Text node containing my text. Seems
> correct??? But it does not get written out. lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF274.93480F89@ca.ibm.com...Lance,
>
> It seems that you must still be missing something. A save
> on an XSD model is essentially just using DOM serialization:
>
> protected void doSave(OutputStream os, Map
> options) throws IOException
> {
> XSDSchema xsdSchema = getSchema();
> if (xsdSchema != null)
> {
> Document document = xsdSchema.getDocument();
>
> if (document == null)
> {
> xsdSchema.updateDocument();
> document = xsdSchema.getDocument();
> }
>
> if (xsdSchema.getElement() == null)
> {
> xsdSchema.updateElement();
> }
>
> doSerialize(os, document, options == null ?
> null : (String)options.get(XSD_ENCODING));
> }
> }
>
> So if you've built the DOM correctly it should be fine.
> Trying printing out the DOM Elements as you modify them
> using XSDResourceImpl.serialize to see if they look as you
> expect. Note that the prototypical schema example produces
> this correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo
> source="http://www.example.com/appinfo"/>
> <xsd:documentation
>
> source="http://www.example.com/documentation">A simple
> recursive complex type
> definition.</xsd:documentation>
> </xsd:annotation>
>
> so if you do it right, it should work...
>
>
> Lance Phillips wrote:
>
> > Thanks Ed... looks like I can find most everything I need
> > there. In
> > addition, I found a better example on how to do the
> > Annotations for
> > SimpleTypes from my post below. It seems to be working...
> > however, when I
> > write the contents of the resource out via a save, the
> > text node under the
> > documentation is not being written out???? Known bug, or
> > am I still missing
> > something?
> >
> > thanks,
> >
> > lp
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > Lance,
> > >
> > > Maybe your aren't adding to, or setting, the black
> > diamond containment
> > > relations, e.g., XSDSchema.getContents()? Have you look
> > in the Javadoc at
> > how
> > > XSDPrototypicalSchema builds various constructs from
> > scratch. You'll need
> > to do
> > > essentially this same kind of thing, but on the fly.
> > Avoid setting values
> > whose
> > > Javadoc says "It is computed from *blah* and should
> > typically not be set
> > > directly." Note that the resolveXyz methods are useful
> > to create
> > placeholders
> > > that can be used in a reference before the referent is
> > created, e.g., the
> > type
> > > of an element where the type is defined later in the
> > schema.
> > >
> > >
> > > Lance Phillips wrote:
> > >
> > > > All,
> > > > I'm working on an xmi reader adapter
> > implementation that can read
> > legacy
> > > > models we have that represent our old approach to
> > xsd. What the reader
> > does
> > > > is interpret what Eclipse XSD element / attribute to
> > create in place of
> > our
> > > > old xsd implementation. I'm running into problems
> > with Attributes and
> > both
> > > > Complex / Simple Types (I'm sure others as I get
> > farther). The problem
> > is
> > > > that when I run into an Attribute representation from
> > our legacy model,
> > I
> > > > use the XSDFactory.eInstance to create a new
> > XSDAttribute. However, I
> > am
> > > > unable to add the Attribute to it's parent (XSDSchema,
> > XSDElement or
> > > > XSDComplexType). What steps am I missing to add
> > Attributes, Types and
> > > > Groups to their parent when processing in an xmi
> > reader adapter
> > > > implementation? It seems to be missing type
> > information that I don't
> > have
> > > > yet as I do not get any of the features for the new
> > entity until I've
> > > > already had to create the entity and add it to a
> > parent. I have also
> > tried
> > > > using the resolveXXX methods on
> > XSDConcreteComponentImpl to no avail.
> > > >
> > > > HELP!!
> > > >
> > > > thanks,
> > > >
> > > > lp
> > >
>
--------------8EFEB04FED663851883D96E8
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>Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
<p>If I use null as the source URI in the prototype example, it still prints
correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo/>
<br>
<xsd:documentation><b>A simple recursive complex type definition</b>.</xsd:documen
<br> </xsd:annotation>
<br> <xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<br> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<br> <xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<br> <xsd:anyAttribute namespace="##other"/>
<br> </xsd:complexType>
<p>Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------8EFEB04FED663851883D96E8--
|
|
|
| Re: Help with reader adapter extension [message #31129 is a reply to message #31060] |
Wed, 01 October 2003 16:04 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------AC145F71347A863FF4956268
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
It means the annotation must be attached to a model, i.e., a schema will
be reached walking up the containers. (After all, the example itself
has the annotation as a child of the complex type.)
Lance Phillips wrote:
> One other important distinction.... I'm adding this annotation as a
> child of a XsdSimpleTypeDefinition. In the documentation in the
> PrototypeSchema it says that the annotation must be attached to a
> schema, does that mean as an immediate child, or simply that it must
> be added to a model? thanks, lp
>
> "Lance Phillips" <lphillips@metamatrix.com> wrote in message
> news:blesil$lfn$1@eclipse.org...I can't figure out what I'm
> missing... I cut and pasted the code from the Prototype.
> The ONLY thing I'm doing differently is that I am not
> setting the source URI. Is that required? When I process my
> model after everything is built, I get an Annotation that
> has a UserInfo EList, the data attribute of that EList
> contains a ElementNSInfo node who's first child is a Text
> node containing my text. Seems correct??? But it does not
> get written out. lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF274.93480F89@ca.ibm.com...Lance,
>
> It seems that you must still be missing
> something. A save on an XSD model is essentially
> just using DOM serialization:
>
> protected void doSave(OutputStream os,
> Map options) throws IOException
> {
> XSDSchema xsdSchema = getSchema();
> if (xsdSchema != null)
> {
> Document document =
> xsdSchema.getDocument();
> if (document == null)
> {
> xsdSchema.updateDocument();
> document =
> xsdSchema.getDocument();
> }
>
> if (xsdSchema.getElement() ==
> null)
> {
> xsdSchema.updateElement();
> }
>
> doSerialize(os, document, options
> == null ? null :
> (String)options.get(XSD_ENCODING));
> }
> }
>
> So if you've built the DOM correctly it should be
> fine. Trying printing out the DOM Elements as you
> modify them using XSDResourceImpl.serialize to see
> if they look as you expect. Note that the
> prototypical schema example produces this
> correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo
> source="http://www.example.com/appinfo"/>
> <xsd:documentation
>
> source="http://www.example.com/documentation">A
> simple
> recursive complex type
> definition.</xsd:documentation>
> </xsd:annotation>
>
> so if you do it right, it should work...
>
>
> Lance Phillips wrote:
>
> > Thanks Ed... looks like I can find most
> > everything I need there. In
> > addition, I found a better example on how to do
> > the Annotations for
> > SimpleTypes from my post below. It seems to be
> > working... however, when I
> > write the contents of the resource out via a
> > save, the text node under the
> > documentation is not being written out????
> > Known bug, or am I still missing
> > something?
> >
> > thanks,
> >
> > lp
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > Lance,
> > >
> > > Maybe your aren't adding to, or setting, the
> > black diamond containment
> > > relations, e.g., XSDSchema.getContents()?
> > Have you look in the Javadoc at
> > how
> > > XSDPrototypicalSchema builds various
> > constructs from scratch. You'll need
> > to do
> > > essentially this same kind of thing, but on
> > the fly. Avoid setting values
> > whose
> > > Javadoc says "It is computed from *blah* and
> > should typically not be set
> > > directly." Note that the resolveXyz methods
> > are useful to create
> > placeholders
> > > that can be used in a reference before the
> > referent is created, e.g., the
> > type
> > > of an element where the type is defined later
> > in the schema.
> > >
> > >
> > > Lance Phillips wrote:
> > >
> > > > All,
> > > > I'm working on an xmi reader adapter
> > implementation that can read
> > legacy
> > > > models we have that represent our old
> > approach to xsd. What the reader
> > does
> > > > is interpret what Eclipse XSD element /
> > attribute to create in place of
> > our
> > > > old xsd implementation. I'm running into
> > problems with Attributes and
> > both
> > > > Complex / Simple Types (I'm sure others as I
> > get farther). The problem
> > is
> > > > that when I run into an Attribute
> > representation from our legacy model,
> > I
> > > > use the XSDFactory.eInstance to create a new
> > XSDAttribute. However, I
> > am
> > > > unable to add the Attribute to it's parent
> > (XSDSchema, XSDElement or
> > > > XSDComplexType). What steps am I missing to
> > add Attributes, Types and
> > > > Groups to their parent when processing in an
> > xmi reader adapter
> > > > implementation? It seems to be missing type
> > information that I don't
> > have
> > > > yet as I do not get any of the features for
> > the new entity until I've
> > > > already had to create the entity and add it
> > to a parent. I have also
> > tried
> > > > using the resolveXXX methods on
> > XSDConcreteComponentImpl to no avail.
> > > >
> > > > HELP!!
> > > >
> > > > thanks,
> > > >
> > > > lp
> > >
>
--------------AC145F71347A863FF4956268
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>It means the annotation must be attached to a model, i.e., a schema
will be reached walking up the containers. (After all, the example
itself has the annotation as a child of the complex type.)
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>One
other important distinction.... I'm adding this annotation as a child of
a XsdSimpleTypeDefinition. In the documentation in the PrototypeSchema
it says that the annotation must be attached to a schema, does that mean
as an immediate child, or simply that it must be added to a model?</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">"Lance
Phillips" <<a href="mailto:lphillips@metamatrix.com">lphillips@metamatrix.com</a>>
wrote in message <a href="news:blesil$lfn$1@eclipse.org">news:blesil$lfn$1@eclipse.org</a>...<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------AC145F71347A863FF4956268--
|
|
|
| Re: Help with reader adapter extension [message #31300 is a reply to message #31094] |
Thu, 02 October 2003 12:35 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0032_01C388B7.CE043200
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
I got it to work with our xsd stuff that is a straight port to xsd =
(I had an extra root element that was causing the save to barf because =
the get schema logic on the resource isn't smart enough to find the =
schema element if there is more than one root element). I can't get =
this to work for our metamodel stuff that is an extension of the xsd =
metamodel. We'd like to run that through the xmi resource as we've =
added many constructs (like multiple roots) that simply won't run =
through the xsd resource, but seem to go ok in the xmi resource. We'd =
also prefer the extension be xmi not xsd for our model as it will not =
represent a valid schema. It looks like the only hang up is the DOM =
elements in the xmi resource. Do you have any direction for us (besides =
stop extending stuff ;) )?=20
thanks,
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF92C.2194DDC1@ca.ibm.com...
Lance,=20
Unfortunately trying figure out what might be the problem is a little =
like reading tea leaves, and in this case, without looking at the cup.=20
If I use null as the source URI in the prototype example, it still =
prints correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" final=3D"#all"=20
mixed=3D"true" name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo/>=20
<xsd:documentation>A simple recursive complex type =
definition.</xsd:documen=20
</xsd:annotation>=20
<xsd:group ref=3D"PTS:simpleRecursiveModelGroupDefinition"/>=20
<xsd:attribute ref=3D"PTS:simpleAttributeDeclaration" =
use=3D"optional"/>=20
<xsd:attributeGroup =
ref=3D"PTS:simpleAttributeGroupDefinition"/>=20
<xsd:anyAttribute namespace=3D"##other"/>=20
</xsd:complexType>=20
Did you trying using XSDResourceImpl.serialize at various times to see =
how things print?=20
=20
Lance Phillips wrote:=20
I can't figure out what I'm missing... I cut and pasted the code =
from the Prototype. The ONLY thing I'm doing differently is that I am =
not setting the source URI. Is that required? When I process my model =
after everything is built, I get an Annotation that has a UserInfo =
EList, the data attribute of that EList contains a ElementNSInfo node =
who's first child is a Text node containing my text. Seems correct??? =
But it does not get written out. lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF274.93480F89@ca.ibm.com...Lance,=20
It seems that you must still be missing something. A save on an =
XSD model is essentially just using DOM serialization:=20
protected void doSave(OutputStream os, Map options) throws =
IOException=20
{=20
XSDSchema xsdSchema =3D getSchema();=20
if (xsdSchema !=3D null)=20
{=20
Document document =3D xsdSchema.getDocument();=20
if (document =3D=3D null)=20
{=20
xsdSchema.updateDocument();=20
document =3D xsdSchema.getDocument();=20
}=20
if (xsdSchema.getElement() =3D=3D null)=20
{=20
xsdSchema.updateElement();=20
}=20
doSerialize(os, document, options =3D=3D null ? null : =
(String)options.get(XSD_ENCODING));=20
}=20
}
So if you've built the DOM correctly it should be fine. Trying =
printing out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to see if they look as you expect. Note that =
the prototypical schema example produces this correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" =
final=3D"#all"=20
mixed=3D"true" =
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo =
source=3D"http://www.example.com/appinfo"/>=20
<xsd:documentation=20
source=3D"http://www.example.com/documentation">A =
simple=20
recursive complex type =
definition.</xsd:documentation>=20
</xsd:annotation>=20
so if you do it right, it should work...=20
=20
Lance Phillips wrote:=20
Thanks Ed... looks like I can find most everything I need there. =
In=20
addition, I found a better example on how to do the Annotations =
for=20
SimpleTypes from my post below. It seems to be working... =
however, when I=20
write the contents of the resource out via a save, the text node =
under the=20
documentation is not being written out???? Known bug, or am I =
still missing=20
something?=20
thanks,=20
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:3F79ECF4.E966FBB3@ca.ibm.com...=20
> Lance,=20
>=20
> Maybe your aren't adding to, or setting, the black diamond =
containment=20
> relations, e.g., XSDSchema.getContents()? Have you look in =
the Javadoc at=20
how=20
> XSDPrototypicalSchema builds various constructs from scratch. =
You'll need=20
to do=20
> essentially this same kind of thing, but on the fly. Avoid =
setting values=20
whose=20
> Javadoc says "It is computed from *blah* and should typically =
not be set=20
> directly." Note that the resolveXyz methods are useful to =
create=20
placeholders=20
> that can be used in a reference before the referent is =
created, e.g., the=20
type=20
> of an element where the type is defined later in the schema.=20
>=20
>=20
> Lance Phillips wrote:=20
>=20
> > All,=20
> > I'm working on an xmi reader adapter implementation that =
can read=20
legacy=20
> > models we have that represent our old approach to xsd. What =
the reader=20
does=20
> > is interpret what Eclipse XSD element / attribute to create =
in place of=20
our=20
> > old xsd implementation. I'm running into problems with =
Attributes and=20
both=20
> > Complex / Simple Types (I'm sure others as I get farther). =
The problem=20
is=20
> > that when I run into an Attribute representation from our =
legacy model,=20
I=20
> > use the XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
am=20
> > unable to add the Attribute to it's parent (XSDSchema, =
XSDElement or=20
> > XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
> > Groups to their parent when processing in an xmi reader =
adapter=20
> > implementation? It seems to be missing type information =
that I don't=20
have=20
> > yet as I do not get any of the features for the new entity =
until I've=20
> > already had to create the entity and add it to a parent. I =
have also=20
tried=20
> > using the resolveXXX methods on XSDConcreteComponentImpl to =
no avail.=20
> >=20
> > HELP!!=20
> >=20
> > thanks,=20
> >=20
> > lp=20
>
------=_NextPart_000_0032_01C388B7.CE043200
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.1226" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> I got it to work =
with our xsd=20
stuff that is a straight port to xsd (I had an extra root element that =
was=20
causing the save to barf because the get schema logic on the resource =
isn't=20
smart enough to find the schema element if there is more than one root=20
element). I can't get this to work for our metamodel stuff that is =
an=20
extension of the xsd metamodel. We'd like to run that through the =
xmi=20
resource as we've added many constructs (like multiple roots) that =
simply won't=20
run through the xsd resource, but seem to go ok in the xmi =
resource. We'd=20
also prefer the extension be xmi not xsd for our model as it will not =
represent=20
a valid schema. It looks like the only hang up is the DOM elements =
in the=20
xmi resource. Do you have any direction for us (besides stop =
extending=20
stuff ;) )? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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:3F7AF92C.2194DDC1@ca.ibm.com">news:3F7AF92C.2194DDC1@ca.ibm.=
com</A>...</DIV>Lance,=20
<P>Unfortunately trying figure out what might be the problem is a =
little like=20
reading tea leaves, and in this case, without looking at the cup.=20
<P>If I use null as the source URI in the prototype example, it still =
prints=20
correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> <xsd:annotation>=20
<BR> =
<xsd:appinfo/>=20
<BR> =
<xsd:documentation><B>A simple recursive complex type=20
definition</B>.</xsd:documen =
<BR> =20
</xsd:annotation> <BR> =
<xsd:group ref=3D"PTS:simpleRecursiveModelGroupDefinition"/>=20
<BR> <xsd:attribute=20
ref=3D"PTS:simpleAttributeDeclaration" use=3D"optional"/>=20
<BR> <xsd:attributeGroup=20
ref=3D"PTS:simpleAttributeGroupDefinition"/>=20
<BR> <xsd:anyAttribute=20
namespace=3D"##other"/> <BR> =
</xsd:complexType>=20
<P>Did you trying using XSDResourceImpl.serialize at various times to =
see how=20
things print? <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>I can't figure out what I'm =
missing... I cut=20
and pasted the code from the Prototype. The ONLY thing I'm =
doing=20
differently is that I am not setting the source URI. Is that=20
required?</FONT></FONT> <FONT face=3DArial><FONT size=3D-1>When =
I process=20
my model after everything is built, I get an Annotation that has a =
UserInfo=20
EList, the data attribute of that EList contains a ElementNSInfo =
node who's=20
first child is a Text node containing my text. Seems =
correct??? =20
But it does not get written out.</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>lp</FONT></FONT>=20
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed=20
Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.=
com</A>...Lance,=20
<P>It seems that you must still be missing something. A save =
on an=20
XSD model is essentially just using DOM serialization:=20
<BLOCKQUOTE><TT> protected void doSave(OutputStream os, Map=20
options) throws IOException</TT> <BR><TT> {</TT>=20
<BR><TT> XSDSchema xsdSchema =3D =
getSchema();</TT>=20
<BR><TT> if (xsdSchema !=3D null)</TT>=20
<BR><TT> {</TT> =
<BR><TT> =20
Document document =3D xsdSchema.getDocument();</TT>=20
<BR><TT> if (document =3D=3D =
null)</TT>=20
<BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateDocument();</TT>=20
<BR><TT> document =3D=20
xsdSchema.getDocument();</TT> =
<BR><TT> =20
}</TT>=20
<P><TT> if (xsdSchema.getElement() =
=3D=3D=20
null)</TT> <BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateElement();</TT> =
<BR><TT> =20
}</TT>=20
<P><TT> doSerialize(os, document, =
options=20
=3D=3D null ? null : (String)options.get(XSD_ENCODING));</TT>=20
<BR><TT> }</TT> <BR><TT> =
}</TT></P></BLOCKQUOTE>So=20
if you've built the DOM correctly it should be fine. Trying =
printing=20
out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to=20
see if they look as you expect. Note that the prototypical =
schema=20
example produces <B>this</B> correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> =
<xsd:annotation>=20
=
<BR> =20
<xsd:appinfo source=3D"<A =
href=3D"http://www.example.com/appinfo"=20
?>http://www.example.com/appinfo"/</A>>=20
=
<BR> =20
<xsd:documentation=20
=
<BR> &nb=
sp; =20
source=3D"<A=20
=
href=3D"http://www.example.com/documentation">http://www.example.com/docu=
mentation</A>"><B>A=20
simple</B>=20
=
<BR><B> =
=20
recursive complex type definition.</B></xsd:documentation>=20
<BR> =
</xsd:annotation>=20
<P>so if you do it right, it should work... <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">Thanks Ed... looks like I can find most=20
everything I need there. In <BR>addition, I found a better =
example=20
on how to do the Annotations for <BR>SimpleTypes from my post=20
below. It seems to be working... however, when I <BR>write =
the=20
contents of the resource out via a save, the text node under the =
<BR>documentation is not being written out???? Known bug, =
or am I=20
still missing <BR>something?=20
<P>thanks,=20
<P>lp <BR>"Ed Merks" <merks@ca.ibm.com> wrote in message =
<BR><A=20
=
href=3D"news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.=
com</A>...=20
<BR>> Lance, <BR>> <BR>> Maybe your aren't adding to, =
or=20
setting, the black diamond containment <BR>> relations, e.g., =
XSDSchema.getContents()? Have you look in the Javadoc at =
<BR>how=20
<BR>> XSDPrototypicalSchema builds various constructs from=20
scratch. You'll need <BR>to do <BR>> essentially this =
same kind=20
of thing, but on the fly. Avoid setting values <BR>whose =
<BR>>=20
Javadoc says "It is computed from *blah* and should typically =
not be set=20
<BR>> directly." Note that the resolveXyz methods are =
useful to=20
create <BR>placeholders <BR>> that can be used in a reference =
before=20
the referent is created, e.g., the <BR>type <BR>> of an =
element where=20
the type is defined later in the schema. <BR>> <BR>> =
<BR>>=20
Lance Phillips wrote: <BR>> <BR>> > All, <BR>>=20
> I'm working on an xmi reader =
adapter=20
implementation that can read <BR>legacy <BR>> > models we =
have=20
that represent our old approach to xsd. What the reader =
<BR>does=20
<BR>> > is interpret what Eclipse XSD element / attribute =
to=20
create in place of <BR>our <BR>> > old xsd =
implementation. =20
I'm running into problems with Attributes and <BR>both <BR>> =
>=20
Complex / Simple Types (I'm sure others as I get farther). =
The=20
problem <BR>is <BR>> > that when I run into an Attribute=20
representation from our legacy model, <BR>I <BR>> > use =
the=20
XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
<BR>am <BR>> > unable to add the Attribute to it's parent=20
(XSDSchema, XSDElement or <BR>> > XSDComplexType). =
What=20
steps am I missing to add Attributes, Types and <BR>> > =
Groups to=20
their parent when processing in an xmi reader adapter <BR>> =
>=20
implementation? It seems to be missing type information =
that I=20
don't <BR>have <BR>> > yet as I do not get any of the =
features for=20
the new entity until I've <BR>> > already had to create =
the entity=20
and add it to a parent. I have also <BR>tried <BR>> =
> using=20
the resolveXXX methods on XSDConcreteComponentImpl to no avail. =
<BR>>=20
> <BR>> > HELP!! <BR>> > <BR>> > thanks, =
<BR>>=20
> <BR>> > lp=20
<BR>></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE> </BLOCKQUOTE></BODY></=
HTML>
------=_NextPart_000_0032_01C388B7.CE043200--
|
|
|
| Re: Help with reader adapter extension [message #31331 is a reply to message #31300] |
Thu, 02 October 2003 12:44 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------9D8364705A4B277E21B91FC6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
Which DOM elements are a problem in the XMI? Just the annotation ones?
Lance Phillips wrote:
> Ed, I got it to work with our xsd stuff that is a straight port to
> xsd (I had an extra root element that was causing the save to barf
> because the get schema logic on the resource isn't smart enough to
> find the schema element if there is more than one root element). I
> can't get this to work for our metamodel stuff that is an extension of
> the xsd metamodel. We'd like to run that through the xmi resource as
> we've added many constructs (like multiple roots) that simply won't
> run through the xsd resource, but seem to go ok in the xmi resource.
> We'd also prefer the extension be xmi not xsd for our model as it will
> not represent a valid schema. It looks like the only hang up is the
> DOM elements in the xmi resource. Do you have any direction for us
> (besides stop extending stuff ;) )? thanks, lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF92C.2194DDC1@ca.ibm.com...Lance,
>
> Unfortunately trying figure out what might be the problem is
> a little like reading tea leaves, and in this case, without
> looking at the cup.
>
> If I use null as the source URI in the prototype example, it
> still prints correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo/>
> <xsd:documentation>A simple recursive complex
> type definition.</xsd:documen
> </xsd:annotation>
> <xsd:group
> ref="PTS:simpleRecursiveModelGroupDefinition"/>
> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
> use="optional"/>
> <xsd:attributeGroup
> ref="PTS:simpleAttributeGroupDefinition"/>
> <xsd:anyAttribute namespace="##other"/>
> </xsd:complexType>
>
> Did you trying using XSDResourceImpl.serialize at various
> times to see how things print?
>
>
> Lance Phillips wrote:
>
> > I can't figure out what I'm missing... I cut and pasted
> > the code from the Prototype. The ONLY thing I'm doing
> > differently is that I am not setting the source URI. Is
> > that required? When I process my model after everything is
> > built, I get an Annotation that has a UserInfo EList, the
> > data attribute of that EList contains a ElementNSInfo node
> > who's first child is a Text node containing my text.
> > Seems correct??? But it does not get written out. lp
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F7AF274.93480F89@ca.ibm.com...Lance,
> >
> > It seems that you must still be missing
> > something. A save on an XSD model is
> > essentially just using DOM serialization:
> >
> > protected void doSave(OutputStream
> > os, Map options) throws IOException
> > {
> > XSDSchema xsdSchema = getSchema();
> >
> > if (xsdSchema != null)
> > {
> > Document document =
> > xsdSchema.getDocument();
> > if (document == null)
> > {
> > xsdSchema.updateDocument();
> > document =
> > xsdSchema.getDocument();
> > }
> >
> > if (xsdSchema.getElement() ==
> > null)
> > {
> > xsdSchema.updateElement();
> > }
> >
> > doSerialize(os, document,
> > options == null ? null :
> > (String)options.get(XSD_ENCODING));
> > }
> > }
> >
> > So if you've built the DOM correctly it should
> > be fine. Trying printing out the DOM Elements
> > as you modify them using
> > XSDResourceImpl.serialize to see if they look as
> > you expect. Note that the prototypical schema
> > example produces this correctly:
> >
> > <xsd:complexType abstract="false"
> > block="#all" final="#all"
> > mixed="true"
> > name="SimpleRecursiveComplexTypeDefinition">
> > <xsd:annotation>
> > <xsd:appinfo
> > source="http://www.example.com/appinfo"/>
> > <xsd:documentation
> >
> > source="http://www.example.com/documentation">A
> > simple
> > recursive complex type
> > definition.</xsd:documentation>
> > </xsd:annotation>
> >
> > so if you do it right, it should work...
> >
> >
> > Lance Phillips wrote:
> >
> > > Thanks Ed... looks like I can find most
> > > everything I need there. In
> > > addition, I found a better example on how to do
> > > the Annotations for
> > > SimpleTypes from my post below. It seems to be
> > > working... however, when I
> > > write the contents of the resource out via a
> > > save, the text node under the
> > > documentation is not being written out????
> > > Known bug, or am I still missing
> > > something?
> > >
> > > thanks,
> > >
> > > lp
> > > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > > Lance,
> > > >
> > > > Maybe your aren't adding to, or setting, the
> > > black diamond containment
> > > > relations, e.g., XSDSchema.getContents()?
> > > Have you look in the Javadoc at
> > > how
> > > > XSDPrototypicalSchema builds various
> > > constructs from scratch. You'll need
> > > to do
> > > > essentially this same kind of thing, but on
> > > the fly. Avoid setting values
> > > whose
> > > > Javadoc says "It is computed from *blah* and
> > > should typically not be set
> > > > directly." Note that the resolveXyz methods
> > > are useful to create
> > > placeholders
> > > > that can be used in a reference before the
> > > referent is created, e.g., the
> > > type
> > > > of an element where the type is defined later
> > > in the schema.
> > > >
> > > >
> > > > Lance Phillips wrote:
> > > >
> > > > > All,
> > > > > I'm working on an xmi reader adapter
> > > implementation that can read
> > > legacy
> > > > > models we have that represent our old
> > > approach to xsd. What the reader
> > > does
> > > > > is interpret what Eclipse XSD element /
> > > attribute to create in place of
> > > our
> > > > > old xsd implementation. I'm running into
> > > problems with Attributes and
> > > both
> > > > > Complex / Simple Types (I'm sure others as
> > > I get farther). The problem
> > > is
> > > > > that when I run into an Attribute
> > > representation from our legacy model,
> > > I
> > > > > use the XSDFactory.eInstance to create a
> > > new XSDAttribute. However, I
> > > am
> > > > > unable to add the Attribute to it's parent
> > > (XSDSchema, XSDElement or
> > > > > XSDComplexType). What steps am I missing
> > > to add Attributes, Types and
> > > > > Groups to their parent when processing in
> > > an xmi reader adapter
> > > > > implementation? It seems to be missing
> > > type information that I don't
> > > have
> > > > > yet as I do not get any of the features for
> > > the new entity until I've
> > > > > already had to create the entity and add it
> > > to a parent. I have also
> > > tried
> > > > > using the resolveXXX methods on
> > > XSDConcreteComponentImpl to no avail.
> > > > >
> > > > > HELP!!
> > > > >
> > > > > thanks,
> > > > >
> > > > > lp
> > > >
> >
--------------9D8364705A4B277E21B91FC6
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>Which DOM elements are a problem in the XMI? Just the annotation
ones?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Ed,
I got it to work with our xsd stuff that is a straight port to xsd (I had
an extra root element that was causing the save to barf because the get
schema logic on the resource isn't smart enough to find the schema element
if there is more than one root element). I can't get this to work
for our metamodel stuff that is an extension of the xsd metamodel.
We'd like to run that through the xmi resource as we've added many constructs
(like multiple roots) that simply won't run through the xsd resource, but
seem to go ok in the xmi resource. We'd also prefer the extension
be xmi not xsd for our model as it will not represent a valid schema.
It looks like the only hang up is the DOM elements in the xmi resource.
Do you have any direction for us (besides stop extending stuff ;)
)?</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:3F7AF92C.2194DDC1@ca.ibm.com">news:3F7AF92C.2194DDC1@ca.ibm.com</a>...Lance,
<p>Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
<p>If I use null as the source URI in the prototype example, it still prints
correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo/>
<br>
<xsd:documentation><b>A simple recursive complex type definition</b>.</xsd:documen
<br> </xsd:annotation>
<br> <xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<br> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<br> <xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<br> <xsd:anyAttribute namespace="##other"/>
<br> </xsd:complexType>
<p>Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------9D8364705A4B277E21B91FC6--
|
|
|
| Re: Help with reader adapter extension [message #31356 is a reply to message #31300] |
Thu, 02 October 2003 14:15 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------EB19169438A3B2F1509BD9BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
Your direct note to me indicated that it's the DOM stuff under the
XSDAnnotations that's causing the grief.
I can imagine that making save work wouldn't be too difficult by
overriding XMLSaveImpl.endSaveFeatures to write out the extra DOM things
associated with the object; you may needs some overrides in the Lookup
stuff to treat some of the XSDAnnotation's features as transient. The
loading seems like a significantly trickier problem. You'd need to
override startElement/endElement to handle all the DOM things, and you'd
need to recognize the situations when you should be doing that, i.e.,
when your DOM-containing object is at the top of the stack you'd want
your special handling to kick in to create DOM nodes.
Lance Phillips wrote:
> Ed, I got it to work with our xsd stuff that is a straight port to
> xsd (I had an extra root element that was causing the save to barf
> because the get schema logic on the resource isn't smart enough to
> find the schema element if there is more than one root element). I
> can't get this to work for our metamodel stuff that is an extension of
> the xsd metamodel. We'd like to run that through the xmi resource as
> we've added many constructs (like multiple roots) that simply won't
> run through the xsd resource, but seem to go ok in the xmi resource.
> We'd also prefer the extension be xmi not xsd for our model as it will
> not represent a valid schema. It looks like the only hang up is the
> DOM elements in the xmi resource. Do you have any direction for us
> (besides stop extending stuff ;) )? thanks, lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF92C.2194DDC1@ca.ibm.com...Lance,
>
> Unfortunately trying figure out what might be the problem is
> a little like reading tea leaves, and in this case, without
> looking at the cup.
>
> If I use null as the source URI in the prototype example, it
> still prints correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo/>
> <xsd:documentation>A simple recursive complex
> type definition.</xsd:documen
> </xsd:annotation>
> <xsd:group
> ref="PTS:simpleRecursiveModelGroupDefinition"/>
> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
> use="optional"/>
> <xsd:attributeGroup
> ref="PTS:simpleAttributeGroupDefinition"/>
> <xsd:anyAttribute namespace="##other"/>
> </xsd:complexType>
>
> Did you trying using XSDResourceImpl.serialize at various
> times to see how things print?
>
>
> Lance Phillips wrote:
>
> > I can't figure out what I'm missing... I cut and pasted
> > the code from the Prototype. The ONLY thing I'm doing
> > differently is that I am not setting the source URI. Is
> > that required? When I process my model after everything is
> > built, I get an Annotation that has a UserInfo EList, the
> > data attribute of that EList contains a ElementNSInfo node
> > who's first child is a Text node containing my text.
> > Seems correct??? But it does not get written out. lp
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F7AF274.93480F89@ca.ibm.com...Lance,
> >
> > It seems that you must still be missing
> > something. A save on an XSD model is
> > essentially just using DOM serialization:
> >
> > protected void doSave(OutputStream
> > os, Map options) throws IOException
> > {
> > XSDSchema xsdSchema = getSchema();
> >
> > if (xsdSchema != null)
> > {
> > Document document =
> > xsdSchema.getDocument();
> > if (document == null)
> > {
> > xsdSchema.updateDocument();
> > document =
> > xsdSchema.getDocument();
> > }
> >
> > if (xsdSchema.getElement() ==
> > null)
> > {
> > xsdSchema.updateElement();
> > }
> >
> > doSerialize(os, document,
> > options == null ? null :
> > (String)options.get(XSD_ENCODING));
> > }
> > }
> >
> > So if you've built the DOM correctly it should
> > be fine. Trying printing out the DOM Elements
> > as you modify them using
> > XSDResourceImpl.serialize to see if they look as
> > you expect. Note that the prototypical schema
> > example produces this correctly:
> >
> > <xsd:complexType abstract="false"
> > block="#all" final="#all"
> > mixed="true"
> > name="SimpleRecursiveComplexTypeDefinition">
> > <xsd:annotation>
> > <xsd:appinfo
> > source="http://www.example.com/appinfo"/>
> > <xsd:documentation
> >
> > source="http://www.example.com/documentation">A
> > simple
> > recursive complex type
> > definition.</xsd:documentation>
> > </xsd:annotation>
> >
> > so if you do it right, it should work...
> >
> >
> > Lance Phillips wrote:
> >
> > > Thanks Ed... looks like I can find most
> > > everything I need there. In
> > > addition, I found a better example on how to do
> > > the Annotations for
> > > SimpleTypes from my post below. It seems to be
> > > working... however, when I
> > > write the contents of the resource out via a
> > > save, the text node under the
> > > documentation is not being written out????
> > > Known bug, or am I still missing
> > > something?
> > >
> > > thanks,
> > >
> > > lp
> > > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > > Lance,
> > > >
> > > > Maybe your aren't adding to, or setting, the
> > > black diamond containment
> > > > relations, e.g., XSDSchema.getContents()?
> > > Have you look in the Javadoc at
> > > how
> > > > XSDPrototypicalSchema builds various
> > > constructs from scratch. You'll need
> > > to do
> > > > essentially this same kind of thing, but on
> > > the fly. Avoid setting values
> > > whose
> > > > Javadoc says "It is computed from *blah* and
> > > should typically not be set
> > > > directly." Note that the resolveXyz methods
> > > are useful to create
> > > placeholders
> > > > that can be used in a reference before the
> > > referent is created, e.g., the
> > > type
> > > > of an element where the type is defined later
> > > in the schema.
> > > >
> > > >
> > > > Lance Phillips wrote:
> > > >
> > > > > All,
> > > > > I'm working on an xmi reader adapter
> > > implementation that can read
> > > legacy
> > > > > models we have that represent our old
> > > approach to xsd. What the reader
> > > does
> > > > > is interpret what Eclipse XSD element /
> > > attribute to create in place of
> > > our
> > > > > old xsd implementation. I'm running into
> > > problems with Attributes and
> > > both
> > > > > Complex / Simple Types (I'm sure others as
> > > I get farther). The problem
> > > is
> > > > > that when I run into an Attribute
> > > representation from our legacy model,
> > > I
> > > > > use the XSDFactory.eInstance to create a
> > > new XSDAttribute. However, I
> > > am
> > > > > unable to add the Attribute to it's parent
> > > (XSDSchema, XSDElement or
> > > > > XSDComplexType). What steps am I missing
> > > to add Attributes, Types and
> > > > > Groups to their parent when processing in
> > > an xmi reader adapter
> > > > > implementation? It seems to be missing
> > > type information that I don't
> > > have
> > > > > yet as I do not get any of the features for
> > > the new entity until I've
> > > > > already had to create the entity and add it
> > > to a parent. I have also
> > > tried
> > > > > using the resolveXXX methods on
> > > XSDConcreteComponentImpl to no avail.
> > > > >
> > > > > HELP!!
> > > > >
> > > > > thanks,
> > > > >
> > > > > lp
> > > >
> >
--------------EB19169438A3B2F1509BD9BF
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>Your direct note to me indicated that it's the DOM stuff under the XSDAnnotations
that's causing the grief.
<p>I can imagine that making save work wouldn't be too difficult by overriding
XMLSaveImpl.endSaveFeatures to write out the extra DOM things associated
with the object; you may needs some overrides in the Lookup stuff to treat
some of the XSDAnnotation's features as transient. The loading seems
like a significantly trickier problem. You'd need to override startElement/endElement
to handle all the DOM things, and you'd need to recognize the situations
when you should be doing that, i.e., when your DOM-containing object is
at the top of the stack you'd want your special handling to kick in to
create DOM nodes.
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Ed,</font></font><font face="Arial"><font size=-1>
I got it to work with our xsd stuff that is a straight port to xsd (I had
an extra root element that was causing the save to barf because the get
schema logic on the resource isn't smart enough to find the schema element
if there is more than one root element). I can't get this to work
for our metamodel stuff that is an extension of the xsd metamodel.
We'd like to run that through the xmi resource as we've added many constructs
(like multiple roots) that simply won't run through the xsd resource, but
seem to go ok in the xmi resource. We'd also prefer the extension
be xmi not xsd for our model as it will not represent a valid schema.
It looks like the only hang up is the DOM elements in the xmi resource.
Do you have any direction for us (besides stop extending stuff ;)
)?</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:3F7AF92C.2194DDC1@ca.ibm.com">news:3F7AF92C.2194DDC1@ca.ibm.com</a>...Lance,
<p>Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
<p>If I use null as the source URI in the prototype example, it still prints
correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo/>
<br>
<xsd:documentation><b>A simple recursive complex type definition</b>.</xsd:documen
<br> </xsd:annotation>
<br> <xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<br> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<br> <xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<br> <xsd:anyAttribute namespace="##other"/>
<br> </xsd:complexType>
<p>Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------EB19169438A3B2F1509BD9BF--
|
|
|
| Re: Help with reader adapter extension [message #579075 is a reply to message #30880] |
Tue, 30 September 2003 20:52 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Lance,
Maybe your aren't adding to, or setting, the black diamond containment
relations, e.g., XSDSchema.getContents()? Have you look in the Javadoc at how
XSDPrototypicalSchema builds various constructs from scratch. You'll need to do
essentially this same kind of thing, but on the fly. Avoid setting values whose
Javadoc says "It is computed from *blah* and should typically not be set
directly." Note that the resolveXyz methods are useful to create placeholders
that can be used in a reference before the referent is created, e.g., the type
of an element where the type is defined later in the schema.
Lance Phillips wrote:
> All,
> I'm working on an xmi reader adapter implementation that can read legacy
> models we have that represent our old approach to xsd. What the reader does
> is interpret what Eclipse XSD element / attribute to create in place of our
> old xsd implementation. I'm running into problems with Attributes and both
> Complex / Simple Types (I'm sure others as I get farther). The problem is
> that when I run into an Attribute representation from our legacy model, I
> use the XSDFactory.eInstance to create a new XSDAttribute. However, I am
> unable to add the Attribute to it's parent (XSDSchema, XSDElement or
> XSDComplexType). What steps am I missing to add Attributes, Types and
> Groups to their parent when processing in an xmi reader adapter
> implementation? It seems to be missing type information that I don't have
> yet as I do not get any of the features for the new entity until I've
> already had to create the entity and add it to a parent. I have also tried
> using the resolveXXX methods on XSDConcreteComponentImpl to no avail.
>
> HELP!!
>
> thanks,
>
> lp
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Help with reader adapter extension [message #579110 is a reply to message #30916] |
Wed, 01 October 2003 14:46 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
Thanks Ed... looks like I can find most everything I need there. In
addition, I found a better example on how to do the Annotations for
SimpleTypes from my post below. It seems to be working... however, when I
write the contents of the resource out via a save, the text node under the
documentation is not being written out???? Known bug, or am I still missing
something?
thanks,
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message
news:3F79ECF4.E966FBB3@ca.ibm.com...
> Lance,
>
> Maybe your aren't adding to, or setting, the black diamond containment
> relations, e.g., XSDSchema.getContents()? Have you look in the Javadoc at
how
> XSDPrototypicalSchema builds various constructs from scratch. You'll need
to do
> essentially this same kind of thing, but on the fly. Avoid setting values
whose
> Javadoc says "It is computed from *blah* and should typically not be set
> directly." Note that the resolveXyz methods are useful to create
placeholders
> that can be used in a reference before the referent is created, e.g., the
type
> of an element where the type is defined later in the schema.
>
>
> Lance Phillips wrote:
>
> > All,
> > I'm working on an xmi reader adapter implementation that can read
legacy
> > models we have that represent our old approach to xsd. What the reader
does
> > is interpret what Eclipse XSD element / attribute to create in place of
our
> > old xsd implementation. I'm running into problems with Attributes and
both
> > Complex / Simple Types (I'm sure others as I get farther). The problem
is
> > that when I run into an Attribute representation from our legacy model,
I
> > use the XSDFactory.eInstance to create a new XSDAttribute. However, I
am
> > unable to add the Attribute to it's parent (XSDSchema, XSDElement or
> > XSDComplexType). What steps am I missing to add Attributes, Types and
> > Groups to their parent when processing in an xmi reader adapter
> > implementation? It seems to be missing type information that I don't
have
> > yet as I do not get any of the features for the new entity until I've
> > already had to create the entity and add it to a parent. I have also
tried
> > using the resolveXXX methods on XSDConcreteComponentImpl to no avail.
> >
> > HELP!!
> >
> > thanks,
> >
> > lp
>
|
|
|
| Re: Help with reader adapter extension [message #579133 is a reply to message #30951] |
Wed, 01 October 2003 15:27 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
--------------93C0315AA641E479F1D76F1C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
It seems that you must still be missing something. A save on an XSD model is
essentially just using DOM serialization:
protected void doSave(OutputStream os, Map options) throws
IOException
{
XSDSchema xsdSchema = getSchema();
if (xsdSchema != null)
{
Document document = xsdSchema.getDocument();
if (document == null)
{
xsdSchema.updateDocument();
document = xsdSchema.getDocument();
}
if (xsdSchema.getElement() == null)
{
xsdSchema.updateElement();
}
doSerialize(os, document, options == null ? null :
(String)options.get(XSD_ENCODING));
}
}
So if you've built the DOM correctly it should be fine. Trying printing out the
DOM Elements as you modify them using XSDResourceImpl.serialize to see if they
look as you expect. Note that the prototypical schema example produces this
correctly:
<xsd:complexType abstract="false" block="#all" final="#all"
mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<xsd:annotation>
<xsd:appinfo source="http://www.example.com/appinfo"/>
<xsd:documentation
source="http://www.example.com/documentation">A simple
recursive complex type definition.</xsd:documentation>
</xsd:annotation>
so if you do it right, it should work...
Lance Phillips wrote:
> Thanks Ed... looks like I can find most everything I need there. In
> addition, I found a better example on how to do the Annotations for
> SimpleTypes from my post below. It seems to be working... however, when I
> write the contents of the resource out via a save, the text node under the
> documentation is not being written out???? Known bug, or am I still missing
> something?
>
> thanks,
>
> lp
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F79ECF4.E966FBB3@ca.ibm.com...
> > Lance,
> >
> > Maybe your aren't adding to, or setting, the black diamond containment
> > relations, e.g., XSDSchema.getContents()? Have you look in the Javadoc at
> how
> > XSDPrototypicalSchema builds various constructs from scratch. You'll need
> to do
> > essentially this same kind of thing, but on the fly. Avoid setting values
> whose
> > Javadoc says "It is computed from *blah* and should typically not be set
> > directly." Note that the resolveXyz methods are useful to create
> placeholders
> > that can be used in a reference before the referent is created, e.g., the
> type
> > of an element where the type is defined later in the schema.
> >
> >
> > Lance Phillips wrote:
> >
> > > All,
> > > I'm working on an xmi reader adapter implementation that can read
> legacy
> > > models we have that represent our old approach to xsd. What the reader
> does
> > > is interpret what Eclipse XSD element / attribute to create in place of
> our
> > > old xsd implementation. I'm running into problems with Attributes and
> both
> > > Complex / Simple Types (I'm sure others as I get farther). The problem
> is
> > > that when I run into an Attribute representation from our legacy model,
> I
> > > use the XSDFactory.eInstance to create a new XSDAttribute. However, I
> am
> > > unable to add the Attribute to it's parent (XSDSchema, XSDElement or
> > > XSDComplexType). What steps am I missing to add Attributes, Types and
> > > Groups to their parent when processing in an xmi reader adapter
> > > implementation? It seems to be missing type information that I don't
> have
> > > yet as I do not get any of the features for the new entity until I've
> > > already had to create the entity and add it to a parent. I have also
> tried
> > > using the resolveXXX methods on XSDConcreteComponentImpl to no avail.
> > >
> > > HELP!!
> > >
> > > thanks,
> > >
> > > lp
> >
--------------93C0315AA641E479F1D76F1C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt><tt></tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt><tt></tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<A HREF="http://www.example.com/appinfo"/">http://www.example.com/appinfo"/</A>>
<br>
<xsd:documentation
<br>
source="<A HREF="http://www.example.com/documentation">http://www.example.com/documentation</A>"><b>A simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE>Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</html>
--------------93C0315AA641E479F1D76F1C--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Help with reader adapter extension [message #579160 is a reply to message #30986] |
Wed, 01 October 2003 15:42 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0016_01C38808.B8FFE5C0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I can't figure out what I'm missing... I cut and pasted the code from =
the Prototype. The ONLY thing I'm doing differently is that I am not =
setting the source URI. Is that required?
When I process my model after everything is built, I get an Annotation =
that has a UserInfo EList, the data attribute of that EList contains a =
ElementNSInfo node who's first child is a Text node containing my text. =
Seems correct??? But it does not get written out.
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF274.93480F89@ca.ibm.com...
Lance,=20
It seems that you must still be missing something. A save on an XSD =
model is essentially just using DOM serialization:=20
protected void doSave(OutputStream os, Map options) throws =
IOException=20
{=20
XSDSchema xsdSchema =3D getSchema();=20
if (xsdSchema !=3D null)=20
{=20
Document document =3D xsdSchema.getDocument();=20
if (document =3D=3D null)=20
{=20
xsdSchema.updateDocument();=20
document =3D xsdSchema.getDocument();=20
}=20
if (xsdSchema.getElement() =3D=3D null)=20
{=20
xsdSchema.updateElement();=20
}=20
doSerialize(os, document, options =3D=3D null ? null : =
(String)options.get(XSD_ENCODING));=20
}=20
}
So if you've built the DOM correctly it should be fine. Trying =
printing out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to see if they look as you expect. Note that =
the prototypical schema example produces this correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" final=3D"#all"=20
mixed=3D"true" name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo source=3D"http://www.example.com/appinfo"/>=20
<xsd:documentation=20
source=3D"http://www.example.com/documentation">A =
simple=20
recursive complex type definition.</xsd:documentation> =
</xsd:annotation>=20
so if you do it right, it should work...=20
=20
Lance Phillips wrote:=20
Thanks Ed... looks like I can find most everything I need there. In =
addition, I found a better example on how to do the Annotations for=20
SimpleTypes from my post below. It seems to be working... however, =
when I=20
write the contents of the resource out via a save, the text node =
under the=20
documentation is not being written out???? Known bug, or am I still =
missing=20
something?=20
thanks,=20
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:3F79ECF4.E966FBB3@ca.ibm.com...=20
> Lance,=20
>=20
> Maybe your aren't adding to, or setting, the black diamond =
containment=20
> relations, e.g., XSDSchema.getContents()? Have you look in the =
Javadoc at=20
how=20
> XSDPrototypicalSchema builds various constructs from scratch. =
You'll need=20
to do=20
> essentially this same kind of thing, but on the fly. Avoid =
setting values=20
whose=20
> Javadoc says "It is computed from *blah* and should typically not =
be set=20
> directly." Note that the resolveXyz methods are useful to create=20
placeholders=20
> that can be used in a reference before the referent is created, =
e.g., the=20
type=20
> of an element where the type is defined later in the schema.=20
>=20
>=20
> Lance Phillips wrote:=20
>=20
> > All,=20
> > I'm working on an xmi reader adapter implementation that can =
read=20
legacy=20
> > models we have that represent our old approach to xsd. What the =
reader=20
does=20
> > is interpret what Eclipse XSD element / attribute to create in =
place of=20
our=20
> > old xsd implementation. I'm running into problems with =
Attributes and=20
both=20
> > Complex / Simple Types (I'm sure others as I get farther). The =
problem=20
is=20
> > that when I run into an Attribute representation from our legacy =
model,=20
I=20
> > use the XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
am=20
> > unable to add the Attribute to it's parent (XSDSchema, =
XSDElement or=20
> > XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
> > Groups to their parent when processing in an xmi reader adapter=20
> > implementation? It seems to be missing type information that I =
don't=20
have=20
> > yet as I do not get any of the features for the new entity until =
I've=20
> > already had to create the entity and add it to a parent. I have =
also=20
tried=20
> > using the resolveXXX methods on XSDConcreteComponentImpl to no =
avail.=20
> >=20
> > HELP!!=20
> >=20
> > thanks,=20
> >=20
> > lp=20
>
------=_NextPart_000_0016_01C38808.B8FFE5C0
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.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I can't figure out what I'm missing... =
I cut and=20
pasted the code from the Prototype. The ONLY thing I'm doing =
differently=20
is that I am not setting the source URI. Is that =
required?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>When I process my model after =
everything is built,=20
I get an Annotation that has a UserInfo EList, the data attribute of =
that EList=20
contains a ElementNSInfo node who's first child is a Text node =
containing my=20
text. Seems correct??? But it does not get written =
out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.=
com</A>...</DIV>Lance,=20
<P>It seems that you must still be missing something. A save on =
an XSD=20
model is essentially just using DOM serialization:=20
<BLOCKQUOTE><TT> protected void doSave(OutputStream os, Map =
options)=20
throws IOException</TT> <BR><TT> {</TT> =
<BR><TT> =20
XSDSchema xsdSchema =3D getSchema();</TT> <BR><TT> =
if=20
(xsdSchema !=3D null)</TT> <BR><TT> {</TT>=20
<BR><TT> Document document =3D=20
xsdSchema.getDocument();</TT> <BR><TT> =
if=20
(document =3D=3D null)</TT> <BR><TT> =
{</TT>=20
<BR><TT> =20
xsdSchema.updateDocument();</TT>=20
<BR><TT> document =3D=20
xsdSchema.getDocument();</TT> <BR><TT> =
}</TT><TT></TT>=20
<P><TT> if (xsdSchema.getElement() =
=3D=3D=20
null)</TT> <BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateElement();</TT> =
<BR><TT> =20
}</TT><TT></TT>=20
<P><TT> doSerialize(os, document, =
options =3D=3D=20
null ? null : (String)options.get(XSD_ENCODING));</TT>=20
<BR><TT> }</TT> <BR><TT> =
}</TT></P></BLOCKQUOTE>So if=20
you've built the DOM correctly it should be fine. Trying =
printing out=20
the DOM Elements as you modify them using XSDResourceImpl.serialize to =
see if=20
they look as you expect. Note that the prototypical schema =
example=20
produces <B>this</B> correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> <xsd:annotation>=20
<BR> =
<xsd:appinfo source=3D"<A href=3D"http://www.example.com/appinfo"=20
?>http://www.example.com/appinfo"/</A>>=20
<BR> =
<xsd:documentation=20
=
<BR> &nb=
sp; =20
source=3D"<A=20
=
href=3D"http://www.example.com/documentation">http://www.example.com/docu=
mentation</A>"><B>A=20
simple</B>=20
=
<BR><B> =
=20
recursive complex type definition.</B></xsd:documentation>=20
<BR> </xsd:annotation> =
<P>so if you do it right, it should work... <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">Thanks Ed... looks like I can find most =
everything I=20
need there. In <BR>addition, I found a better example on how =
to do the=20
Annotations for <BR>SimpleTypes from my post below. It seems =
to be=20
working... however, when I <BR>write the contents of the resource =
out via a=20
save, the text node under the <BR>documentation is not being written =
out???? Known bug, or am I still missing <BR>something?=20
<P>thanks,=20
<P>lp <BR>"Ed Merks" <merks@ca.ibm.com> wrote in message =
<BR><A=20
=
href=3D"news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.=
com</A>...=20
<BR>> Lance, <BR>> <BR>> Maybe your aren't adding to, or =
setting,=20
the black diamond containment <BR>> relations, e.g.,=20
XSDSchema.getContents()? Have you look in the Javadoc at =
<BR>how=20
<BR>> XSDPrototypicalSchema builds various constructs from =
scratch. =20
You'll need <BR>to do <BR>> essentially this same kind of thing, =
but on=20
the fly. Avoid setting values <BR>whose <BR>> Javadoc says =
"It is=20
computed from *blah* and should typically not be set <BR>>=20
directly." Note that the resolveXyz methods are useful to =
create=20
<BR>placeholders <BR>> that can be used in a reference before the =
referent is created, e.g., the <BR>type <BR>> of an element where =
the=20
type is defined later in the schema. <BR>> <BR>> <BR>> =
Lance=20
Phillips wrote: <BR>> <BR>> > All, <BR>>=20
> I'm working on an xmi reader adapter=20
implementation that can read <BR>legacy <BR>> > models we have =
that=20
represent our old approach to xsd. What the reader <BR>does =
<BR>>=20
> is interpret what Eclipse XSD element / attribute to create in =
place of=20
<BR>our <BR>> > old xsd implementation. I'm running into =
problems with Attributes and <BR>both <BR>> > Complex / Simple =
Types=20
(I'm sure others as I get farther). The problem <BR>is =
<BR>> >=20
that when I run into an Attribute representation from our legacy =
model,=20
<BR>I <BR>> > use the XSDFactory.eInstance to create a new=20
XSDAttribute. However, I <BR>am <BR>> > unable to add =
the=20
Attribute to it's parent (XSDSchema, XSDElement or <BR>> >=20
XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
<BR>> > Groups to their parent when processing in an xmi =
reader=20
adapter <BR>> > implementation? It seems to be missing =
type=20
information that I don't <BR>have <BR>> > yet as I do not get =
any of=20
the features for the new entity until I've <BR>> > already had =
to=20
create the entity and add it to a parent. I have also =
<BR>tried=20
<BR>> > using the resolveXXX methods on =
XSDConcreteComponentImpl to no=20
avail. <BR>> > <BR>> > HELP!! <BR>> > <BR>> =
>=20
thanks, <BR>> > <BR>> > lp=20
<BR>></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML >
------=_NextPart_000_0016_01C38808.B8FFE5C0--
|
|
|
| Re: Help with reader adapter extension [message #579178 is a reply to message #31019] |
Wed, 01 October 2003 15:50 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0022_01C38809.CDA176A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
One other important distinction.... I'm adding this annotation as a =
child of a XsdSimpleTypeDefinition. In the documentation in the =
PrototypeSchema it says that the annotation must be attached to a =
schema, does that mean as an immediate child, or simply that it must be =
added to a model?
thanks,
lp
"Lance Phillips" <lphillips@metamatrix.com> wrote in message =
news:blesil$lfn$1@eclipse.org...
I can't figure out what I'm missing... I cut and pasted the code from =
the Prototype. The ONLY thing I'm doing differently is that I am not =
setting the source URI. Is that required?
When I process my model after everything is built, I get an Annotation =
that has a UserInfo EList, the data attribute of that EList contains a =
ElementNSInfo node who's first child is a Text node containing my text. =
Seems correct??? But it does not get written out.
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF274.93480F89@ca.ibm.com...
Lance,=20
It seems that you must still be missing something. A save on an XSD =
model is essentially just using DOM serialization:=20
protected void doSave(OutputStream os, Map options) throws =
IOException=20
{=20
XSDSchema xsdSchema =3D getSchema();=20
if (xsdSchema !=3D null)=20
{=20
Document document =3D xsdSchema.getDocument();=20
if (document =3D=3D null)=20
{=20
xsdSchema.updateDocument();=20
document =3D xsdSchema.getDocument();=20
}=20
if (xsdSchema.getElement() =3D=3D null)=20
{=20
xsdSchema.updateElement();=20
}=20
doSerialize(os, document, options =3D=3D null ? null : =
(String)options.get(XSD_ENCODING));=20
}=20
}
So if you've built the DOM correctly it should be fine. Trying =
printing out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to see if they look as you expect. Note that =
the prototypical schema example produces this correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" =
final=3D"#all"=20
mixed=3D"true" =
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo source=3D"http://www.example.com/appinfo"/> =
<xsd:documentation=20
source=3D"http://www.example.com/documentation">A =
simple=20
recursive complex type =
definition.</xsd:documentation>=20
</xsd:annotation>=20
so if you do it right, it should work...=20
=20
Lance Phillips wrote:=20
Thanks Ed... looks like I can find most everything I need there. =
In=20
addition, I found a better example on how to do the Annotations =
for=20
SimpleTypes from my post below. It seems to be working... =
however, when I=20
write the contents of the resource out via a save, the text node =
under the=20
documentation is not being written out???? Known bug, or am I =
still missing=20
something?=20
thanks,=20
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:3F79ECF4.E966FBB3@ca.ibm.com...=20
> Lance,=20
>=20
> Maybe your aren't adding to, or setting, the black diamond =
containment=20
> relations, e.g., XSDSchema.getContents()? Have you look in the =
Javadoc at=20
how=20
> XSDPrototypicalSchema builds various constructs from scratch. =
You'll need=20
to do=20
> essentially this same kind of thing, but on the fly. Avoid =
setting values=20
whose=20
> Javadoc says "It is computed from *blah* and should typically =
not be set=20
> directly." Note that the resolveXyz methods are useful to =
create=20
placeholders=20
> that can be used in a reference before the referent is created, =
e.g., the=20
type=20
> of an element where the type is defined later in the schema.=20
>=20
>=20
> Lance Phillips wrote:=20
>=20
> > All,=20
> > I'm working on an xmi reader adapter implementation that =
can read=20
legacy=20
> > models we have that represent our old approach to xsd. What =
the reader=20
does=20
> > is interpret what Eclipse XSD element / attribute to create in =
place of=20
our=20
> > old xsd implementation. I'm running into problems with =
Attributes and=20
both=20
> > Complex / Simple Types (I'm sure others as I get farther). =
The problem=20
is=20
> > that when I run into an Attribute representation from our =
legacy model,=20
I=20
> > use the XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
am=20
> > unable to add the Attribute to it's parent (XSDSchema, =
XSDElement or=20
> > XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
> > Groups to their parent when processing in an xmi reader =
adapter=20
> > implementation? It seems to be missing type information that =
I don't=20
have=20
> > yet as I do not get any of the features for the new entity =
until I've=20
> > already had to create the entity and add it to a parent. I =
have also=20
tried=20
> > using the resolveXXX methods on XSDConcreteComponentImpl to no =
avail.=20
> >=20
> > HELP!!=20
> >=20
> > thanks,=20
> >=20
> > lp=20
>
------=_NextPart_000_0022_01C38809.CDA176A0
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.1226" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>One other important distinction.... I'm =
adding this=20
annotation as a child of a XsdSimpleTypeDefinition. In the =
documentation=20
in the PrototypeSchema it says that the annotation must be attached to a =
schema,=20
does that mean as an immediate child, or simply that it must be added to =
a=20
model?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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>"Lance Phillips" <<A=20
=
href=3D"mailto:lphillips@metamatrix.com">lphillips@metamatrix.com</A>>=
wrote=20
in message <A=20
=
href=3D"news:blesil$lfn$1@eclipse.org">news:blesil$lfn$1@eclipse.org</A>.=
...</DIV>
<DIV><FONT face=3DArial size=3D2>I can't figure out what I'm =
missing... I cut and=20
pasted the code from the Prototype. The ONLY thing I'm doing =
differently=20
is that I am not setting the source URI. Is that =
required?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>When I process my model after =
everything is=20
built, I get an Annotation that has a UserInfo EList, the data =
attribute of=20
that EList contains a ElementNSInfo node who's first child is a Text =
node=20
containing my text. Seems correct??? But it does not get =
written=20
out.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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=20
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>> wrote in =
message <A=20
=
href=3D"news:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.=
com</A>...</DIV>Lance,=20
<P>It seems that you must still be missing something. A save =
on an XSD=20
model is essentially just using DOM serialization:=20
<BLOCKQUOTE><TT> protected void doSave(OutputStream os, Map =
options)=20
throws IOException</TT> <BR><TT> {</TT> =
<BR><TT> =20
XSDSchema xsdSchema =3D getSchema();</TT> =
<BR><TT> if=20
(xsdSchema !=3D null)</TT> <BR><TT> {</TT>=20
<BR><TT> Document document =3D=20
xsdSchema.getDocument();</TT> =
<BR><TT> if=20
(document =3D=3D null)</TT> <BR><TT> =
{</TT>=20
<BR><TT> =20
xsdSchema.updateDocument();</TT>=20
<BR><TT> document =3D=20
xsdSchema.getDocument();</TT> =
<BR><TT> =20
}</TT><TT></TT>=20
<P><TT> if (xsdSchema.getElement() =
=3D=3D=20
null)</TT> <BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateElement();</TT> =
<BR><TT> =20
}</TT><TT></TT>=20
<P><TT> doSerialize(os, document, =
options =3D=3D=20
null ? null : (String)options.get(XSD_ENCODING));</TT>=20
<BR><TT> }</TT> <BR><TT> =
}</TT></P></BLOCKQUOTE>So=20
if you've built the DOM correctly it should be fine. Trying =
printing=20
out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to=20
see if they look as you expect. Note that the prototypical =
schema=20
example produces <B>this</B> correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> =
<xsd:annotation>=20
=
<BR> =20
<xsd:appinfo source=3D"<A href=3D"http://www.example.com/appinfo" =
?>http://www.example.com/appinfo"/</A>>=20
=
<BR> =20
<xsd:documentation=20
=
<BR> &nb=
sp; =20
source=3D"<A=20
=
href=3D"http://www.example.com/documentation">http://www.example.com/docu=
mentation</A>"><B>A=20
simple</B>=20
=
<BR><B> =
=20
recursive complex type definition.</B></xsd:documentation>=20
<BR> =
</xsd:annotation>=20
<P>so if you do it right, it should work... <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">Thanks Ed... looks like I can find most =
everything=20
I need there. In <BR>addition, I found a better example on =
how to do=20
the Annotations for <BR>SimpleTypes from my post below. It =
seems to=20
be working... however, when I <BR>write the contents of the =
resource out=20
via a save, the text node under the <BR>documentation is not being =
written=20
out???? Known bug, or am I still missing <BR>something?=20
<P>thanks,=20
<P>lp <BR>"Ed Merks" <merks@ca.ibm.com> wrote in message =
<BR><A=20
=
href=3D"news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.=
com</A>...=20
<BR>> Lance, <BR>> <BR>> Maybe your aren't adding to, or =
setting,=20
the black diamond containment <BR>> relations, e.g.,=20
XSDSchema.getContents()? Have you look in the Javadoc at =
<BR>how=20
<BR>> XSDPrototypicalSchema builds various constructs from=20
scratch. You'll need <BR>to do <BR>> essentially this =
same kind=20
of thing, but on the fly. Avoid setting values <BR>whose =
<BR>>=20
Javadoc says "It is computed from *blah* and should typically not =
be set=20
<BR>> directly." Note that the resolveXyz methods are =
useful to=20
create <BR>placeholders <BR>> that can be used in a reference =
before=20
the referent is created, e.g., the <BR>type <BR>> of an element =
where=20
the type is defined later in the schema. <BR>> <BR>> =
<BR>> Lance=20
Phillips wrote: <BR>> <BR>> > All, <BR>>=20
> I'm working on an xmi reader adapter=20
implementation that can read <BR>legacy <BR>> > models we =
have that=20
represent our old approach to xsd. What the reader <BR>does =
<BR>>=20
> is interpret what Eclipse XSD element / attribute to create =
in place=20
of <BR>our <BR>> > old xsd implementation. I'm running =
into=20
problems with Attributes and <BR>both <BR>> > Complex / =
Simple Types=20
(I'm sure others as I get farther). The problem <BR>is =
<BR>> >=20
that when I run into an Attribute representation from our legacy =
model,=20
<BR>I <BR>> > use the XSDFactory.eInstance to create a new=20
XSDAttribute. However, I <BR>am <BR>> > unable to add =
the=20
Attribute to it's parent (XSDSchema, XSDElement or <BR>> >=20
XSDComplexType). What steps am I missing to add Attributes, =
Types=20
and <BR>> > Groups to their parent when processing in an xmi =
reader=20
adapter <BR>> > implementation? It seems to be missing =
type=20
information that I don't <BR>have <BR>> > yet as I do not =
get any of=20
the features for the new entity until I've <BR>> > already =
had to=20
create the entity and add it to a parent. I have also =
<BR>tried=20
<BR>> > using the resolveXXX methods on =
XSDConcreteComponentImpl to=20
no avail. <BR>> > <BR>> > HELP!! <BR>> > =
<BR>> >=20
thanks, <BR>> > <BR>> > lp=20
<BR>></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE> </BODY></HTML>
------=_NextPart_000_0022_01C38809.CDA176A0--
|
|
|
| Re: Help with reader adapter extension [message #579224 is a reply to message #31019] |
Wed, 01 October 2003 15:56 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
--------------8EFEB04FED663851883D96E8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
If I use null as the source URI in the prototype example, it still
prints correctly:
<xsd:complexType abstract="false" block="#all" final="#all"
mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<xsd:annotation>
<xsd:appinfo/>
<xsd:documentation>A simple recursive complex type
definition.</xsd:documen
</xsd:annotation>
<xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<xsd:anyAttribute namespace="##other"/>
</xsd:complexType>
Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
Lance Phillips wrote:
> I can't figure out what I'm missing... I cut and pasted the code from
> the Prototype. The ONLY thing I'm doing differently is that I am not
> setting the source URI. Is that required? When I process my model
> after everything is built, I get an Annotation that has a UserInfo
> EList, the data attribute of that EList contains a ElementNSInfo node
> who's first child is a Text node containing my text. Seems
> correct??? But it does not get written out. lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF274.93480F89@ca.ibm.com...Lance,
>
> It seems that you must still be missing something. A save
> on an XSD model is essentially just using DOM serialization:
>
> protected void doSave(OutputStream os, Map
> options) throws IOException
> {
> XSDSchema xsdSchema = getSchema();
> if (xsdSchema != null)
> {
> Document document = xsdSchema.getDocument();
>
> if (document == null)
> {
> xsdSchema.updateDocument();
> document = xsdSchema.getDocument();
> }
>
> if (xsdSchema.getElement() == null)
> {
> xsdSchema.updateElement();
> }
>
> doSerialize(os, document, options == null ?
> null : (String)options.get(XSD_ENCODING));
> }
> }
>
> So if you've built the DOM correctly it should be fine.
> Trying printing out the DOM Elements as you modify them
> using XSDResourceImpl.serialize to see if they look as you
> expect. Note that the prototypical schema example produces
> this correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo
> source="http://www.example.com/appinfo"/>
> <xsd:documentation
>
> source="http://www.example.com/documentation">A simple
> recursive complex type
> definition.</xsd:documentation>
> </xsd:annotation>
>
> so if you do it right, it should work...
>
>
> Lance Phillips wrote:
>
> > Thanks Ed... looks like I can find most everything I need
> > there. In
> > addition, I found a better example on how to do the
> > Annotations for
> > SimpleTypes from my post below. It seems to be working...
> > however, when I
> > write the contents of the resource out via a save, the
> > text node under the
> > documentation is not being written out???? Known bug, or
> > am I still missing
> > something?
> >
> > thanks,
> >
> > lp
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > Lance,
> > >
> > > Maybe your aren't adding to, or setting, the black
> > diamond containment
> > > relations, e.g., XSDSchema.getContents()? Have you look
> > in the Javadoc at
> > how
> > > XSDPrototypicalSchema builds various constructs from
> > scratch. You'll need
> > to do
> > > essentially this same kind of thing, but on the fly.
> > Avoid setting values
> > whose
> > > Javadoc says "It is computed from *blah* and should
> > typically not be set
> > > directly." Note that the resolveXyz methods are useful
> > to create
> > placeholders
> > > that can be used in a reference before the referent is
> > created, e.g., the
> > type
> > > of an element where the type is defined later in the
> > schema.
> > >
> > >
> > > Lance Phillips wrote:
> > >
> > > > All,
> > > > I'm working on an xmi reader adapter
> > implementation that can read
> > legacy
> > > > models we have that represent our old approach to
> > xsd. What the reader
> > does
> > > > is interpret what Eclipse XSD element / attribute to
> > create in place of
> > our
> > > > old xsd implementation. I'm running into problems
> > with Attributes and
> > both
> > > > Complex / Simple Types (I'm sure others as I get
> > farther). The problem
> > is
> > > > that when I run into an Attribute representation from
> > our legacy model,
> > I
> > > > use the XSDFactory.eInstance to create a new
> > XSDAttribute. However, I
> > am
> > > > unable to add the Attribute to it's parent (XSDSchema,
> > XSDElement or
> > > > XSDComplexType). What steps am I missing to add
> > Attributes, Types and
> > > > Groups to their parent when processing in an xmi
> > reader adapter
> > > > implementation? It seems to be missing type
> > information that I don't
> > have
> > > > yet as I do not get any of the features for the new
> > entity until I've
> > > > already had to create the entity and add it to a
> > parent. I have also
> > tried
> > > > using the resolveXXX methods on
> > XSDConcreteComponentImpl to no avail.
> > > >
> > > > HELP!!
> > > >
> > > > thanks,
> > > >
> > > > lp
> > >
>
--------------8EFEB04FED663851883D96E8
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>Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
<p>If I use null as the source URI in the prototype example, it still prints
correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo/>
<br>
<xsd:documentation><b>A simple recursive complex type definition</b>.</xsd:documen
<br> </xsd:annotation>
<br> <xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<br> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<br> <xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<br> <xsd:anyAttribute namespace="##other"/>
<br> </xsd:complexType>
<p>Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------8EFEB04FED663851883D96E8--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Help with reader adapter extension [message #579260 is a reply to message #31060] |
Wed, 01 October 2003 16:04 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
--------------AC145F71347A863FF4956268
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
It means the annotation must be attached to a model, i.e., a schema will
be reached walking up the containers. (After all, the example itself
has the annotation as a child of the complex type.)
Lance Phillips wrote:
> One other important distinction.... I'm adding this annotation as a
> child of a XsdSimpleTypeDefinition. In the documentation in the
> PrototypeSchema it says that the annotation must be attached to a
> schema, does that mean as an immediate child, or simply that it must
> be added to a model? thanks, lp
>
> "Lance Phillips" <lphillips@metamatrix.com> wrote in message
> news:blesil$lfn$1@eclipse.org...I can't figure out what I'm
> missing... I cut and pasted the code from the Prototype.
> The ONLY thing I'm doing differently is that I am not
> setting the source URI. Is that required? When I process my
> model after everything is built, I get an Annotation that
> has a UserInfo EList, the data attribute of that EList
> contains a ElementNSInfo node who's first child is a Text
> node containing my text. Seems correct??? But it does not
> get written out. lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF274.93480F89@ca.ibm.com...Lance,
>
> It seems that you must still be missing
> something. A save on an XSD model is essentially
> just using DOM serialization:
>
> protected void doSave(OutputStream os,
> Map options) throws IOException
> {
> XSDSchema xsdSchema = getSchema();
> if (xsdSchema != null)
> {
> Document document =
> xsdSchema.getDocument();
> if (document == null)
> {
> xsdSchema.updateDocument();
> document =
> xsdSchema.getDocument();
> }
>
> if (xsdSchema.getElement() ==
> null)
> {
> xsdSchema.updateElement();
> }
>
> doSerialize(os, document, options
> == null ? null :
> (String)options.get(XSD_ENCODING));
> }
> }
>
> So if you've built the DOM correctly it should be
> fine. Trying printing out the DOM Elements as you
> modify them using XSDResourceImpl.serialize to see
> if they look as you expect. Note that the
> prototypical schema example produces this
> correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo
> source="http://www.example.com/appinfo"/>
> <xsd:documentation
>
> source="http://www.example.com/documentation">A
> simple
> recursive complex type
> definition.</xsd:documentation>
> </xsd:annotation>
>
> so if you do it right, it should work...
>
>
> Lance Phillips wrote:
>
> > Thanks Ed... looks like I can find most
> > everything I need there. In
> > addition, I found a better example on how to do
> > the Annotations for
> > SimpleTypes from my post below. It seems to be
> > working... however, when I
> > write the contents of the resource out via a
> > save, the text node under the
> > documentation is not being written out????
> > Known bug, or am I still missing
> > something?
> >
> > thanks,
> >
> > lp
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > Lance,
> > >
> > > Maybe your aren't adding to, or setting, the
> > black diamond containment
> > > relations, e.g., XSDSchema.getContents()?
> > Have you look in the Javadoc at
> > how
> > > XSDPrototypicalSchema builds various
> > constructs from scratch. You'll need
> > to do
> > > essentially this same kind of thing, but on
> > the fly. Avoid setting values
> > whose
> > > Javadoc says "It is computed from *blah* and
> > should typically not be set
> > > directly." Note that the resolveXyz methods
> > are useful to create
> > placeholders
> > > that can be used in a reference before the
> > referent is created, e.g., the
> > type
> > > of an element where the type is defined later
> > in the schema.
> > >
> > >
> > > Lance Phillips wrote:
> > >
> > > > All,
> > > > I'm working on an xmi reader adapter
> > implementation that can read
> > legacy
> > > > models we have that represent our old
> > approach to xsd. What the reader
> > does
> > > > is interpret what Eclipse XSD element /
> > attribute to create in place of
> > our
> > > > old xsd implementation. I'm running into
> > problems with Attributes and
> > both
> > > > Complex / Simple Types (I'm sure others as I
> > get farther). The problem
> > is
> > > > that when I run into an Attribute
> > representation from our legacy model,
> > I
> > > > use the XSDFactory.eInstance to create a new
> > XSDAttribute. However, I
> > am
> > > > unable to add the Attribute to it's parent
> > (XSDSchema, XSDElement or
> > > > XSDComplexType). What steps am I missing to
> > add Attributes, Types and
> > > > Groups to their parent when processing in an
> > xmi reader adapter
> > > > implementation? It seems to be missing type
> > information that I don't
> > have
> > > > yet as I do not get any of the features for
> > the new entity until I've
> > > > already had to create the entity and add it
> > to a parent. I have also
> > tried
> > > > using the resolveXXX methods on
> > XSDConcreteComponentImpl to no avail.
> > > >
> > > > HELP!!
> > > >
> > > > thanks,
> > > >
> > > > lp
> > >
>
--------------AC145F71347A863FF4956268
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>It means the annotation must be attached to a model, i.e., a schema
will be reached walking up the containers. (After all, the example
itself has the annotation as a child of the complex type.)
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>One
other important distinction.... I'm adding this annotation as a child of
a XsdSimpleTypeDefinition. In the documentation in the PrototypeSchema
it says that the annotation must be attached to a schema, does that mean
as an immediate child, or simply that it must be added to a model?</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">"Lance
Phillips" <<a href="mailto:lphillips@metamatrix.com">lphillips@metamatrix.com</a>>
wrote in message <a href="news:blesil$lfn$1@eclipse.org">news:blesil$lfn$1@eclipse.org</a>...<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------AC145F71347A863FF4956268--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Help with reader adapter extension [message #579401 is a reply to message #31094] |
Thu, 02 October 2003 12:35 |
Lance Phillips
Messages: 210
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
------=_NextPart_000_0032_01C388B7.CE043200
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Ed,
I got it to work with our xsd stuff that is a straight port to xsd =
(I had an extra root element that was causing the save to barf because =
the get schema logic on the resource isn't smart enough to find the =
schema element if there is more than one root element). I can't get =
this to work for our metamodel stuff that is an extension of the xsd =
metamodel. We'd like to run that through the xmi resource as we've =
added many constructs (like multiple roots) that simply won't run =
through the xsd resource, but seem to go ok in the xmi resource. We'd =
also prefer the extension be xmi not xsd for our model as it will not =
represent a valid schema. It looks like the only hang up is the DOM =
elements in the xmi resource. Do you have any direction for us (besides =
stop extending stuff ;) )?=20
thanks,
lp
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF92C.2194DDC1@ca.ibm.com...
Lance,=20
Unfortunately trying figure out what might be the problem is a little =
like reading tea leaves, and in this case, without looking at the cup.=20
If I use null as the source URI in the prototype example, it still =
prints correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" final=3D"#all"=20
mixed=3D"true" name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo/>=20
<xsd:documentation>A simple recursive complex type =
definition.</xsd:documen=20
</xsd:annotation>=20
<xsd:group ref=3D"PTS:simpleRecursiveModelGroupDefinition"/>=20
<xsd:attribute ref=3D"PTS:simpleAttributeDeclaration" =
use=3D"optional"/>=20
<xsd:attributeGroup =
ref=3D"PTS:simpleAttributeGroupDefinition"/>=20
<xsd:anyAttribute namespace=3D"##other"/>=20
</xsd:complexType>=20
Did you trying using XSDResourceImpl.serialize at various times to see =
how things print?=20
=20
Lance Phillips wrote:=20
I can't figure out what I'm missing... I cut and pasted the code =
from the Prototype. The ONLY thing I'm doing differently is that I am =
not setting the source URI. Is that required? When I process my model =
after everything is built, I get an Annotation that has a UserInfo =
EList, the data attribute of that EList contains a ElementNSInfo node =
who's first child is a Text node containing my text. Seems correct??? =
But it does not get written out. lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:3F7AF274.93480F89@ca.ibm.com...Lance,=20
It seems that you must still be missing something. A save on an =
XSD model is essentially just using DOM serialization:=20
protected void doSave(OutputStream os, Map options) throws =
IOException=20
{=20
XSDSchema xsdSchema =3D getSchema();=20
if (xsdSchema !=3D null)=20
{=20
Document document =3D xsdSchema.getDocument();=20
if (document =3D=3D null)=20
{=20
xsdSchema.updateDocument();=20
document =3D xsdSchema.getDocument();=20
}=20
if (xsdSchema.getElement() =3D=3D null)=20
{=20
xsdSchema.updateElement();=20
}=20
doSerialize(os, document, options =3D=3D null ? null : =
(String)options.get(XSD_ENCODING));=20
}=20
}
So if you've built the DOM correctly it should be fine. Trying =
printing out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to see if they look as you expect. Note that =
the prototypical schema example produces this correctly:=20
<xsd:complexType abstract=3D"false" block=3D"#all" =
final=3D"#all"=20
mixed=3D"true" =
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<xsd:annotation>=20
<xsd:appinfo =
source=3D"http://www.example.com/appinfo"/>=20
<xsd:documentation=20
source=3D"http://www.example.com/documentation">A =
simple=20
recursive complex type =
definition.</xsd:documentation>=20
</xsd:annotation>=20
so if you do it right, it should work...=20
=20
Lance Phillips wrote:=20
Thanks Ed... looks like I can find most everything I need there. =
In=20
addition, I found a better example on how to do the Annotations =
for=20
SimpleTypes from my post below. It seems to be working... =
however, when I=20
write the contents of the resource out via a save, the text node =
under the=20
documentation is not being written out???? Known bug, or am I =
still missing=20
something?=20
thanks,=20
lp=20
"Ed Merks" <merks@ca.ibm.com> wrote in message=20
news:3F79ECF4.E966FBB3@ca.ibm.com...=20
> Lance,=20
>=20
> Maybe your aren't adding to, or setting, the black diamond =
containment=20
> relations, e.g., XSDSchema.getContents()? Have you look in =
the Javadoc at=20
how=20
> XSDPrototypicalSchema builds various constructs from scratch. =
You'll need=20
to do=20
> essentially this same kind of thing, but on the fly. Avoid =
setting values=20
whose=20
> Javadoc says "It is computed from *blah* and should typically =
not be set=20
> directly." Note that the resolveXyz methods are useful to =
create=20
placeholders=20
> that can be used in a reference before the referent is =
created, e.g., the=20
type=20
> of an element where the type is defined later in the schema.=20
>=20
>=20
> Lance Phillips wrote:=20
>=20
> > All,=20
> > I'm working on an xmi reader adapter implementation that =
can read=20
legacy=20
> > models we have that represent our old approach to xsd. What =
the reader=20
does=20
> > is interpret what Eclipse XSD element / attribute to create =
in place of=20
our=20
> > old xsd implementation. I'm running into problems with =
Attributes and=20
both=20
> > Complex / Simple Types (I'm sure others as I get farther). =
The problem=20
is=20
> > that when I run into an Attribute representation from our =
legacy model,=20
I=20
> > use the XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
am=20
> > unable to add the Attribute to it's parent (XSDSchema, =
XSDElement or=20
> > XSDComplexType). What steps am I missing to add Attributes, =
Types and=20
> > Groups to their parent when processing in an xmi reader =
adapter=20
> > implementation? It seems to be missing type information =
that I don't=20
have=20
> > yet as I do not get any of the features for the new entity =
until I've=20
> > already had to create the entity and add it to a parent. I =
have also=20
tried=20
> > using the resolveXXX methods on XSDConcreteComponentImpl to =
no avail.=20
> >=20
> > HELP!!=20
> >=20
> > thanks,=20
> >=20
> > lp=20
>
------=_NextPart_000_0032_01C388B7.CE043200
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.1226" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Ed,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2> I got it to work =
with our xsd=20
stuff that is a straight port to xsd (I had an extra root element that =
was=20
causing the save to barf because the get schema logic on the resource =
isn't=20
smart enough to find the schema element if there is more than one root=20
element). I can't get this to work for our metamodel stuff that is =
an=20
extension of the xsd metamodel. We'd like to run that through the =
xmi=20
resource as we've added many constructs (like multiple roots) that =
simply won't=20
run through the xsd resource, but seem to go ok in the xmi =
resource. We'd=20
also prefer the extension be xmi not xsd for our model as it will not =
represent=20
a valid schema. It looks like the only hang up is the DOM elements =
in the=20
xmi resource. Do you have any direction for us (besides stop =
extending=20
stuff ;) )? </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>thanks,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </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:3F7AF92C.2194DDC1@ca.ibm.com">news:3F7AF92C.2194DDC1@ca.ibm.=
com</A>...</DIV>Lance,=20
<P>Unfortunately trying figure out what might be the problem is a =
little like=20
reading tea leaves, and in this case, without looking at the cup.=20
<P>If I use null as the source URI in the prototype example, it still =
prints=20
correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> <xsd:annotation>=20
<BR> =
<xsd:appinfo/>=20
<BR> =
<xsd:documentation><B>A simple recursive complex type=20
definition</B>.</xsd:documen =
<BR> =20
</xsd:annotation> <BR> =
<xsd:group ref=3D"PTS:simpleRecursiveModelGroupDefinition"/>=20
<BR> <xsd:attribute=20
ref=3D"PTS:simpleAttributeDeclaration" use=3D"optional"/>=20
<BR> <xsd:attributeGroup=20
ref=3D"PTS:simpleAttributeGroupDefinition"/>=20
<BR> <xsd:anyAttribute=20
namespace=3D"##other"/> <BR> =
</xsd:complexType>=20
<P>Did you trying using XSDResourceImpl.serialize at various times to =
see how=20
things print? <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">
<STYLE></STYLE>
<FONT face=3DArial><FONT size=3D-1>I can't figure out what I'm =
missing... I cut=20
and pasted the code from the Prototype. The ONLY thing I'm =
doing=20
differently is that I am not setting the source URI. Is that=20
required?</FONT></FONT> <FONT face=3DArial><FONT size=3D-1>When =
I process=20
my model after everything is built, I get an Annotation that has a =
UserInfo=20
EList, the data attribute of that EList contains a ElementNSInfo =
node who's=20
first child is a Text node containing my text. Seems =
correct??? =20
But it does not get written out.</FONT></FONT> <FONT =
face=3DArial><FONT=20
size=3D-1>lp</FONT></FONT>=20
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Ed=20
Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.=
com</A>...Lance,=20
<P>It seems that you must still be missing something. A save =
on an=20
XSD model is essentially just using DOM serialization:=20
<BLOCKQUOTE><TT> protected void doSave(OutputStream os, Map=20
options) throws IOException</TT> <BR><TT> {</TT>=20
<BR><TT> XSDSchema xsdSchema =3D =
getSchema();</TT>=20
<BR><TT> if (xsdSchema !=3D null)</TT>=20
<BR><TT> {</TT> =
<BR><TT> =20
Document document =3D xsdSchema.getDocument();</TT>=20
<BR><TT> if (document =3D=3D =
null)</TT>=20
<BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateDocument();</TT>=20
<BR><TT> document =3D=20
xsdSchema.getDocument();</TT> =
<BR><TT> =20
}</TT>=20
<P><TT> if (xsdSchema.getElement() =
=3D=3D=20
null)</TT> <BR><TT> {</TT>=20
<BR><TT> =20
xsdSchema.updateElement();</TT> =
<BR><TT> =20
}</TT>=20
<P><TT> doSerialize(os, document, =
options=20
=3D=3D null ? null : (String)options.get(XSD_ENCODING));</TT>=20
<BR><TT> }</TT> <BR><TT> =
}</TT></P></BLOCKQUOTE>So=20
if you've built the DOM correctly it should be fine. Trying =
printing=20
out the DOM Elements as you modify them using =
XSDResourceImpl.serialize to=20
see if they look as you expect. Note that the prototypical =
schema=20
example produces <B>this</B> correctly:=20
<P> <xsd:complexType abstract=3D"false" =
block=3D"#all"=20
final=3D"#all" <BR> =
mixed=3D"true"=20
name=3D"SimpleRecursiveComplexTypeDefinition">=20
<BR> =
<xsd:annotation>=20
=
<BR> =20
<xsd:appinfo source=3D"<A =
href=3D"http://www.example.com/appinfo"=20
?>http://www.example.com/appinfo"/</A>>=20
=
<BR> =20
<xsd:documentation=20
=
<BR> &nb=
sp; =20
source=3D"<A=20
=
href=3D"http://www.example.com/documentation">http://www.example.com/docu=
mentation</A>"><B>A=20
simple</B>=20
=
<BR><B> =
=20
recursive complex type definition.</B></xsd:documentation>=20
<BR> =
</xsd:annotation>=20
<P>so if you do it right, it should work... <BR> =20
<P>Lance Phillips wrote:=20
<BLOCKQUOTE TYPE=3D"CITE">Thanks Ed... looks like I can find most=20
everything I need there. In <BR>addition, I found a better =
example=20
on how to do the Annotations for <BR>SimpleTypes from my post=20
below. It seems to be working... however, when I <BR>write =
the=20
contents of the resource out via a save, the text node under the =
<BR>documentation is not being written out???? Known bug, =
or am I=20
still missing <BR>something?=20
<P>thanks,=20
<P>lp <BR>"Ed Merks" <merks@ca.ibm.com> wrote in message =
<BR><A=20
=
href=3D"news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.=
com</A>...=20
<BR>> Lance, <BR>> <BR>> Maybe your aren't adding to, =
or=20
setting, the black diamond containment <BR>> relations, e.g., =
XSDSchema.getContents()? Have you look in the Javadoc at =
<BR>how=20
<BR>> XSDPrototypicalSchema builds various constructs from=20
scratch. You'll need <BR>to do <BR>> essentially this =
same kind=20
of thing, but on the fly. Avoid setting values <BR>whose =
<BR>>=20
Javadoc says "It is computed from *blah* and should typically =
not be set=20
<BR>> directly." Note that the resolveXyz methods are =
useful to=20
create <BR>placeholders <BR>> that can be used in a reference =
before=20
the referent is created, e.g., the <BR>type <BR>> of an =
element where=20
the type is defined later in the schema. <BR>> <BR>> =
<BR>>=20
Lance Phillips wrote: <BR>> <BR>> > All, <BR>>=20
> I'm working on an xmi reader =
adapter=20
implementation that can read <BR>legacy <BR>> > models we =
have=20
that represent our old approach to xsd. What the reader =
<BR>does=20
<BR>> > is interpret what Eclipse XSD element / attribute =
to=20
create in place of <BR>our <BR>> > old xsd =
implementation. =20
I'm running into problems with Attributes and <BR>both <BR>> =
>=20
Complex / Simple Types (I'm sure others as I get farther). =
The=20
problem <BR>is <BR>> > that when I run into an Attribute=20
representation from our legacy model, <BR>I <BR>> > use =
the=20
XSDFactory.eInstance to create a new XSDAttribute. =
However, I=20
<BR>am <BR>> > unable to add the Attribute to it's parent=20
(XSDSchema, XSDElement or <BR>> > XSDComplexType). =
What=20
steps am I missing to add Attributes, Types and <BR>> > =
Groups to=20
their parent when processing in an xmi reader adapter <BR>> =
>=20
implementation? It seems to be missing type information =
that I=20
don't <BR>have <BR>> > yet as I do not get any of the =
features for=20
the new entity until I've <BR>> > already had to create =
the entity=20
and add it to a parent. I have also <BR>tried <BR>> =
> using=20
the resolveXXX methods on XSDConcreteComponentImpl to no avail. =
<BR>>=20
> <BR>> > HELP!! <BR>> > <BR>> > thanks, =
<BR>>=20
> <BR>> > lp=20
<BR>></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE> </BLOCKQUOTE></BODY></=
HTML>
------=_NextPart_000_0032_01C388B7.CE043200--
|
|
|
| Re: Help with reader adapter extension [message #579430 is a reply to message #31300] |
Thu, 02 October 2003 12:44 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
--------------9D8364705A4B277E21B91FC6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
Which DOM elements are a problem in the XMI? Just the annotation ones?
Lance Phillips wrote:
> Ed, I got it to work with our xsd stuff that is a straight port to
> xsd (I had an extra root element that was causing the save to barf
> because the get schema logic on the resource isn't smart enough to
> find the schema element if there is more than one root element). I
> can't get this to work for our metamodel stuff that is an extension of
> the xsd metamodel. We'd like to run that through the xmi resource as
> we've added many constructs (like multiple roots) that simply won't
> run through the xsd resource, but seem to go ok in the xmi resource.
> We'd also prefer the extension be xmi not xsd for our model as it will
> not represent a valid schema. It looks like the only hang up is the
> DOM elements in the xmi resource. Do you have any direction for us
> (besides stop extending stuff ;) )? thanks, lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF92C.2194DDC1@ca.ibm.com...Lance,
>
> Unfortunately trying figure out what might be the problem is
> a little like reading tea leaves, and in this case, without
> looking at the cup.
>
> If I use null as the source URI in the prototype example, it
> still prints correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo/>
> <xsd:documentation>A simple recursive complex
> type definition.</xsd:documen
> </xsd:annotation>
> <xsd:group
> ref="PTS:simpleRecursiveModelGroupDefinition"/>
> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
> use="optional"/>
> <xsd:attributeGroup
> ref="PTS:simpleAttributeGroupDefinition"/>
> <xsd:anyAttribute namespace="##other"/>
> </xsd:complexType>
>
> Did you trying using XSDResourceImpl.serialize at various
> times to see how things print?
>
>
> Lance Phillips wrote:
>
> > I can't figure out what I'm missing... I cut and pasted
> > the code from the Prototype. The ONLY thing I'm doing
> > differently is that I am not setting the source URI. Is
> > that required? When I process my model after everything is
> > built, I get an Annotation that has a UserInfo EList, the
> > data attribute of that EList contains a ElementNSInfo node
> > who's first child is a Text node containing my text.
> > Seems correct??? But it does not get written out. lp
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F7AF274.93480F89@ca.ibm.com...Lance,
> >
> > It seems that you must still be missing
> > something. A save on an XSD model is
> > essentially just using DOM serialization:
> >
> > protected void doSave(OutputStream
> > os, Map options) throws IOException
> > {
> > XSDSchema xsdSchema = getSchema();
> >
> > if (xsdSchema != null)
> > {
> > Document document =
> > xsdSchema.getDocument();
> > if (document == null)
> > {
> > xsdSchema.updateDocument();
> > document =
> > xsdSchema.getDocument();
> > }
> >
> > if (xsdSchema.getElement() ==
> > null)
> > {
> > xsdSchema.updateElement();
> > }
> >
> > doSerialize(os, document,
> > options == null ? null :
> > (String)options.get(XSD_ENCODING));
> > }
> > }
> >
> > So if you've built the DOM correctly it should
> > be fine. Trying printing out the DOM Elements
> > as you modify them using
> > XSDResourceImpl.serialize to see if they look as
> > you expect. Note that the prototypical schema
> > example produces this correctly:
> >
> > <xsd:complexType abstract="false"
> > block="#all" final="#all"
> > mixed="true"
> > name="SimpleRecursiveComplexTypeDefinition">
> > <xsd:annotation>
> > <xsd:appinfo
> > source="http://www.example.com/appinfo"/>
> > <xsd:documentation
> >
> > source="http://www.example.com/documentation">A
> > simple
> > recursive complex type
> > definition.</xsd:documentation>
> > </xsd:annotation>
> >
> > so if you do it right, it should work...
> >
> >
> > Lance Phillips wrote:
> >
> > > Thanks Ed... looks like I can find most
> > > everything I need there. In
> > > addition, I found a better example on how to do
> > > the Annotations for
> > > SimpleTypes from my post below. It seems to be
> > > working... however, when I
> > > write the contents of the resource out via a
> > > save, the text node under the
> > > documentation is not being written out????
> > > Known bug, or am I still missing
> > > something?
> > >
> > > thanks,
> > >
> > > lp
> > > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > > Lance,
> > > >
> > > > Maybe your aren't adding to, or setting, the
> > > black diamond containment
> > > > relations, e.g., XSDSchema.getContents()?
> > > Have you look in the Javadoc at
> > > how
> > > > XSDPrototypicalSchema builds various
> > > constructs from scratch. You'll need
> > > to do
> > > > essentially this same kind of thing, but on
> > > the fly. Avoid setting values
> > > whose
> > > > Javadoc says "It is computed from *blah* and
> > > should typically not be set
> > > > directly." Note that the resolveXyz methods
> > > are useful to create
> > > placeholders
> > > > that can be used in a reference before the
> > > referent is created, e.g., the
> > > type
> > > > of an element where the type is defined later
> > > in the schema.
> > > >
> > > >
> > > > Lance Phillips wrote:
> > > >
> > > > > All,
> > > > > I'm working on an xmi reader adapter
> > > implementation that can read
> > > legacy
> > > > > models we have that represent our old
> > > approach to xsd. What the reader
> > > does
> > > > > is interpret what Eclipse XSD element /
> > > attribute to create in place of
> > > our
> > > > > old xsd implementation. I'm running into
> > > problems with Attributes and
> > > both
> > > > > Complex / Simple Types (I'm sure others as
> > > I get farther). The problem
> > > is
> > > > > that when I run into an Attribute
> > > representation from our legacy model,
> > > I
> > > > > use the XSDFactory.eInstance to create a
> > > new XSDAttribute. However, I
> > > am
> > > > > unable to add the Attribute to it's parent
> > > (XSDSchema, XSDElement or
> > > > > XSDComplexType). What steps am I missing
> > > to add Attributes, Types and
> > > > > Groups to their parent when processing in
> > > an xmi reader adapter
> > > > > implementation? It seems to be missing
> > > type information that I don't
> > > have
> > > > > yet as I do not get any of the features for
> > > the new entity until I've
> > > > > already had to create the entity and add it
> > > to a parent. I have also
> > > tried
> > > > > using the resolveXXX methods on
> > > XSDConcreteComponentImpl to no avail.
> > > > >
> > > > > HELP!!
> > > > >
> > > > > thanks,
> > > > >
> > > > > lp
> > > >
> >
--------------9D8364705A4B277E21B91FC6
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>Which DOM elements are a problem in the XMI? Just the annotation
ones?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Ed,
I got it to work with our xsd stuff that is a straight port to xsd (I had
an extra root element that was causing the save to barf because the get
schema logic on the resource isn't smart enough to find the schema element
if there is more than one root element). I can't get this to work
for our metamodel stuff that is an extension of the xsd metamodel.
We'd like to run that through the xmi resource as we've added many constructs
(like multiple roots) that simply won't run through the xsd resource, but
seem to go ok in the xmi resource. We'd also prefer the extension
be xmi not xsd for our model as it will not represent a valid schema.
It looks like the only hang up is the DOM elements in the xmi resource.
Do you have any direction for us (besides stop extending stuff ;)
)?</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:3F7AF92C.2194DDC1@ca.ibm.com">news:3F7AF92C.2194DDC1@ca.ibm.com</a>...Lance,
<p>Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
<p>If I use null as the source URI in the prototype example, it still prints
correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo/>
<br>
<xsd:documentation><b>A simple recursive complex type definition</b>.</xsd:documen
<br> </xsd:annotation>
<br> <xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<br> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<br> <xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<br> <xsd:anyAttribute namespace="##other"/>
<br> </xsd:complexType>
<p>Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------9D8364705A4B277E21B91FC6--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Help with reader adapter extension [message #579453 is a reply to message #31300] |
Thu, 02 October 2003 14:15 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
--------------EB19169438A3B2F1509BD9BF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lance,
Your direct note to me indicated that it's the DOM stuff under the
XSDAnnotations that's causing the grief.
I can imagine that making save work wouldn't be too difficult by
overriding XMLSaveImpl.endSaveFeatures to write out the extra DOM things
associated with the object; you may needs some overrides in the Lookup
stuff to treat some of the XSDAnnotation's features as transient. The
loading seems like a significantly trickier problem. You'd need to
override startElement/endElement to handle all the DOM things, and you'd
need to recognize the situations when you should be doing that, i.e.,
when your DOM-containing object is at the top of the stack you'd want
your special handling to kick in to create DOM nodes.
Lance Phillips wrote:
> Ed, I got it to work with our xsd stuff that is a straight port to
> xsd (I had an extra root element that was causing the save to barf
> because the get schema logic on the resource isn't smart enough to
> find the schema element if there is more than one root element). I
> can't get this to work for our metamodel stuff that is an extension of
> the xsd metamodel. We'd like to run that through the xmi resource as
> we've added many constructs (like multiple roots) that simply won't
> run through the xsd resource, but seem to go ok in the xmi resource.
> We'd also prefer the extension be xmi not xsd for our model as it will
> not represent a valid schema. It looks like the only hang up is the
> DOM elements in the xmi resource. Do you have any direction for us
> (besides stop extending stuff ;) )? thanks, lp
>
> "Ed Merks" <merks@ca.ibm.com> wrote in message
> news:3F7AF92C.2194DDC1@ca.ibm.com...Lance,
>
> Unfortunately trying figure out what might be the problem is
> a little like reading tea leaves, and in this case, without
> looking at the cup.
>
> If I use null as the source URI in the prototype example, it
> still prints correctly:
>
> <xsd:complexType abstract="false" block="#all"
> final="#all"
> mixed="true"
> name="SimpleRecursiveComplexTypeDefinition">
> <xsd:annotation>
> <xsd:appinfo/>
> <xsd:documentation>A simple recursive complex
> type definition.</xsd:documen
> </xsd:annotation>
> <xsd:group
> ref="PTS:simpleRecursiveModelGroupDefinition"/>
> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
> use="optional"/>
> <xsd:attributeGroup
> ref="PTS:simpleAttributeGroupDefinition"/>
> <xsd:anyAttribute namespace="##other"/>
> </xsd:complexType>
>
> Did you trying using XSDResourceImpl.serialize at various
> times to see how things print?
>
>
> Lance Phillips wrote:
>
> > I can't figure out what I'm missing... I cut and pasted
> > the code from the Prototype. The ONLY thing I'm doing
> > differently is that I am not setting the source URI. Is
> > that required? When I process my model after everything is
> > built, I get an Annotation that has a UserInfo EList, the
> > data attribute of that EList contains a ElementNSInfo node
> > who's first child is a Text node containing my text.
> > Seems correct??? But it does not get written out. lp
> >
> > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > news:3F7AF274.93480F89@ca.ibm.com...Lance,
> >
> > It seems that you must still be missing
> > something. A save on an XSD model is
> > essentially just using DOM serialization:
> >
> > protected void doSave(OutputStream
> > os, Map options) throws IOException
> > {
> > XSDSchema xsdSchema = getSchema();
> >
> > if (xsdSchema != null)
> > {
> > Document document =
> > xsdSchema.getDocument();
> > if (document == null)
> > {
> > xsdSchema.updateDocument();
> > document =
> > xsdSchema.getDocument();
> > }
> >
> > if (xsdSchema.getElement() ==
> > null)
> > {
> > xsdSchema.updateElement();
> > }
> >
> > doSerialize(os, document,
> > options == null ? null :
> > (String)options.get(XSD_ENCODING));
> > }
> > }
> >
> > So if you've built the DOM correctly it should
> > be fine. Trying printing out the DOM Elements
> > as you modify them using
> > XSDResourceImpl.serialize to see if they look as
> > you expect. Note that the prototypical schema
> > example produces this correctly:
> >
> > <xsd:complexType abstract="false"
> > block="#all" final="#all"
> > mixed="true"
> > name="SimpleRecursiveComplexTypeDefinition">
> > <xsd:annotation>
> > <xsd:appinfo
> > source="http://www.example.com/appinfo"/>
> > <xsd:documentation
> >
> > source="http://www.example.com/documentation">A
> > simple
> > recursive complex type
> > definition.</xsd:documentation>
> > </xsd:annotation>
> >
> > so if you do it right, it should work...
> >
> >
> > Lance Phillips wrote:
> >
> > > Thanks Ed... looks like I can find most
> > > everything I need there. In
> > > addition, I found a better example on how to do
> > > the Annotations for
> > > SimpleTypes from my post below. It seems to be
> > > working... however, when I
> > > write the contents of the resource out via a
> > > save, the text node under the
> > > documentation is not being written out????
> > > Known bug, or am I still missing
> > > something?
> > >
> > > thanks,
> > >
> > > lp
> > > "Ed Merks" <merks@ca.ibm.com> wrote in message
> > > news:3F79ECF4.E966FBB3@ca.ibm.com...
> > > > Lance,
> > > >
> > > > Maybe your aren't adding to, or setting, the
> > > black diamond containment
> > > > relations, e.g., XSDSchema.getContents()?
> > > Have you look in the Javadoc at
> > > how
> > > > XSDPrototypicalSchema builds various
> > > constructs from scratch. You'll need
> > > to do
> > > > essentially this same kind of thing, but on
> > > the fly. Avoid setting values
> > > whose
> > > > Javadoc says "It is computed from *blah* and
> > > should typically not be set
> > > > directly." Note that the resolveXyz methods
> > > are useful to create
> > > placeholders
> > > > that can be used in a reference before the
> > > referent is created, e.g., the
> > > type
> > > > of an element where the type is defined later
> > > in the schema.
> > > >
> > > >
> > > > Lance Phillips wrote:
> > > >
> > > > > All,
> > > > > I'm working on an xmi reader adapter
> > > implementation that can read
> > > legacy
> > > > > models we have that represent our old
> > > approach to xsd. What the reader
> > > does
> > > > > is interpret what Eclipse XSD element /
> > > attribute to create in place of
> > > our
> > > > > old xsd implementation. I'm running into
> > > problems with Attributes and
> > > both
> > > > > Complex / Simple Types (I'm sure others as
> > > I get farther). The problem
> > > is
> > > > > that when I run into an Attribute
> > > representation from our legacy model,
> > > I
> > > > > use the XSDFactory.eInstance to create a
> > > new XSDAttribute. However, I
> > > am
> > > > > unable to add the Attribute to it's parent
> > > (XSDSchema, XSDElement or
> > > > > XSDComplexType). What steps am I missing
> > > to add Attributes, Types and
> > > > > Groups to their parent when processing in
> > > an xmi reader adapter
> > > > > implementation? It seems to be missing
> > > type information that I don't
> > > have
> > > > > yet as I do not get any of the features for
> > > the new entity until I've
> > > > > already had to create the entity and add it
> > > to a parent. I have also
> > > tried
> > > > > using the resolveXXX methods on
> > > XSDConcreteComponentImpl to no avail.
> > > > >
> > > > > HELP!!
> > > > >
> > > > > thanks,
> > > > >
> > > > > lp
> > > >
> >
--------------EB19169438A3B2F1509BD9BF
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>Your direct note to me indicated that it's the DOM stuff under the XSDAnnotations
that's causing the grief.
<p>I can imagine that making save work wouldn't be too difficult by overriding
XMLSaveImpl.endSaveFeatures to write out the extra DOM things associated
with the object; you may needs some overrides in the Lookup stuff to treat
some of the XSDAnnotation's features as transient. The loading seems
like a significantly trickier problem. You'd need to override startElement/endElement
to handle all the DOM things, and you'd need to recognize the situations
when you should be doing that, i.e., when your DOM-containing object is
at the top of the stack you'd want your special handling to kick in to
create DOM nodes.
<br>
<p>Lance Phillips wrote:
<blockquote TYPE=CITE> <font face="Arial"><font size=-1>Ed,</font></font><font face="Arial"><font size=-1>
I got it to work with our xsd stuff that is a straight port to xsd (I had
an extra root element that was causing the save to barf because the get
schema logic on the resource isn't smart enough to find the schema element
if there is more than one root element). I can't get this to work
for our metamodel stuff that is an extension of the xsd metamodel.
We'd like to run that through the xmi resource as we've added many constructs
(like multiple roots) that simply won't run through the xsd resource, but
seem to go ok in the xmi resource. We'd also prefer the extension
be xmi not xsd for our model as it will not represent a valid schema.
It looks like the only hang up is the DOM elements in the xmi resource.
Do you have any direction for us (besides stop extending stuff ;)
)?</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:3F7AF92C.2194DDC1@ca.ibm.com">news:3F7AF92C.2194DDC1@ca.ibm.com</a>...Lance,
<p>Unfortunately trying figure out what might be the problem is a little
like reading tea leaves, and in this case, without looking at the cup.
<p>If I use null as the source URI in the prototype example, it still prints
correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo/>
<br>
<xsd:documentation><b>A simple recursive complex type definition</b>.</xsd:documen
<br> </xsd:annotation>
<br> <xsd:group ref="PTS:simpleRecursiveModelGroupDefinition"/>
<br> <xsd:attribute ref="PTS:simpleAttributeDeclaration"
use="optional"/>
<br> <xsd:attributeGroup ref="PTS:simpleAttributeGroupDefinition"/>
<br> <xsd:anyAttribute namespace="##other"/>
<br> </xsd:complexType>
<p>Did you trying using XSDResourceImpl.serialize at various times to see
how things print?
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE"><style></style>
<font face="Arial"><font size=-1>I
can't figure out what I'm missing... I cut and pasted the code from the
Prototype. The ONLY thing I'm doing differently is that I am not
setting the source URI. Is that required?</font></font> <font face="Arial"><font size=-1>When
I process my model after everything is built, I get an Annotation that
has a UserInfo EList, the data attribute of that EList contains a ElementNSInfo
node who's first child is a Text node containing my text. Seems correct???
But it does not get written out.</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:3F7AF274.93480F89@ca.ibm.com">news:3F7AF274.93480F89@ca.ibm.com</a>...Lance,
<p>It seems that you must still be missing something. A save on an
XSD model is essentially just using DOM serialization:
<blockquote><tt> protected void doSave(OutputStream os, Map options)
throws IOException</tt>
<br><tt> {</tt>
<br><tt> XSDSchema xsdSchema = getSchema();</tt>
<br><tt> if (xsdSchema != null)</tt>
<br><tt> {</tt>
<br><tt> Document document = xsdSchema.getDocument();</tt>
<br><tt> if (document == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateDocument();</tt>
<br><tt> document = xsdSchema.getDocument();</tt>
<br><tt> }</tt>
<p><tt> if (xsdSchema.getElement() == null)</tt>
<br><tt> {</tt>
<br><tt> xsdSchema.updateElement();</tt>
<br><tt> }</tt>
<p><tt> doSerialize(os, document, options
== null ? null : (String)options.get(XSD_ENCODING));</tt>
<br><tt> }</tt>
<br><tt> }</tt></blockquote>
So if you've built the DOM correctly it should be fine. Trying printing
out the DOM Elements as you modify them using XSDResourceImpl.serialize
to see if they look as you expect. Note that the prototypical schema
example produces <b>this</b> correctly:
<p> <xsd:complexType abstract="false" block="#all"
final="#all"
<br> mixed="true" name="SimpleRecursiveComplexTypeDefinition">
<br> <xsd:annotation>
<br>
<xsd:appinfo source="<a href="http://www.example.com/appinfo" ?>http://www.example.com/appinfo"/</a>>
<br>
<xsd:documentation
<br>
source="<a href="http://www.example.com/documentation">http://www.example.com/documentation</a>"><b>A
simple</b>
<br><b>
recursive complex type definition.</b></xsd:documentation>
<br> </xsd:annotation>
<p>so if you do it right, it should work...
<br>
<p>Lance Phillips wrote:
<blockquote TYPE="CITE">Thanks Ed... looks like I can find most everything
I need there. In
<br>addition, I found a better example on how to do the Annotations for
<br>SimpleTypes from my post below. It seems to be working... however,
when I
<br>write the contents of the resource out via a save, the text node under
the
<br>documentation is not being written out???? Known bug, or am I
still missing
<br>something?
<p>thanks,
<p>lp
<br>"Ed Merks" <merks@ca.ibm.com> wrote in message
<br><a href="news:3F79ECF4.E966FBB3@ca.ibm.com">news:3F79ECF4.E966FBB3@ca.ibm.com</a>...
<br>> Lance,
<br>>
<br>> Maybe your aren't adding to, or setting, the black diamond containment
<br>> relations, e.g., XSDSchema.getContents()? Have you look in
the Javadoc at
<br>how
<br>> XSDPrototypicalSchema builds various constructs from scratch.
You'll need
<br>to do
<br>> essentially this same kind of thing, but on the fly. Avoid
setting values
<br>whose
<br>> Javadoc says "It is computed from *blah* and should typically not
be set
<br>> directly." Note that the resolveXyz methods are useful to create
<br>placeholders
<br>> that can be used in a reference before the referent is created, e.g.,
the
<br>type
<br>> of an element where the type is defined later in the schema.
<br>>
<br>>
<br>> Lance Phillips wrote:
<br>>
<br>> > All,
<br>> > I'm working on an xmi reader adapter implementation
that can read
<br>legacy
<br>> > models we have that represent our old approach to xsd. What
the reader
<br>does
<br>> > is interpret what Eclipse XSD element / attribute to create in
place of
<br>our
<br>> > old xsd implementation. I'm running into problems with Attributes
and
<br>both
<br>> > Complex / Simple Types (I'm sure others as I get farther).
The problem
<br>is
<br>> > that when I run into an Attribute representation from our legacy
model,
<br>I
<br>> > use the XSDFactory.eInstance to create a new XSDAttribute.
However, I
<br>am
<br>> > unable to add the Attribute to it's parent (XSDSchema, XSDElement
or
<br>> > XSDComplexType). What steps am I missing to add Attributes,
Types and
<br>> > Groups to their parent when processing in an xmi reader adapter
<br>> > implementation? It seems to be missing type information that
I don't
<br>have
<br>> > yet as I do not get any of the features for the new entity until
I've
<br>> > already had to create the entity and add it to a parent.
I have also
<br>tried
<br>> > using the resolveXXX methods on XSDConcreteComponentImpl to no
avail.
<br>> >
<br>> > HELP!!
<br>> >
<br>> > thanks,
<br>> >
<br>> > lp
<br>></blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</body>
</html>
--------------EB19169438A3B2F1509BD9BF--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 20 00:21:47 GMT 2024
Powered by FUDForum. Page generated in 0.05901 seconds |
] 
Search
Help
Register
Login
Home
