[Announce] Stylus Studio 2006 Release 2 Now Available
[announce] Hey Everyone, Release 2 of Stylus Studio 2006 has just been released. The following are some of the highlights of Stylus Studio 2006 Release 2 XML Enterprise Edition: * Enhanced EDI Support: Stylus Studio's EDI-to-XML and XML-to-EDI tools now support hundreds of message and transaction set types of EDIFACT and X12 - across dozens of versions - allowing EDI to be used as easily as XML as input to XSLT and XQuery programs. And those same programs can write output through the adapter, generating EDI transparently and automatically. Stylus Studio supports the newest release of X12, 5030, keeping the tradition of providing comprehensive support of available versions of X12. Preliminary versions of EDIFACT are also supported. Stylus Studio can now automatically convert to and from EDIFACT versions from the prototype 88-1 to the present D05A version. The International Air Transport Association dialect of EDI, IATA PADIS, an EDI standard for air transportation, is also supported. Learn more at: http://www.stylusstudio.com/edi/ * Convert IATA to XML Schema: A new Document Wizard allows you to convert an IATA documents to XML Schema, simplifying the verification of IATA files converted to XML. * Invoke Web Services from XQuery: Use the Stylus Studio Web Service Call Composer to design and test any Web service invocation, then generate the XQuery code needed to invoke the same SOAP request directly in your XQuery application - Learn more at: http://www.stylusstudio.com/xquery.html * Integration with xqDoc: Generate user-friendly documentation of your XQuery libraries and modules for reference purposes - learn more at: http://www.stylusstudio.com/xquery/xqdoc.html * Support for Saxon 8.7 XSLT and XQuery Processor: Updated support for developing applications using the Saxon schema-aware XQuery and XSLT processor - learn more at: http://www.stylusstudio.com/saxon_xquery_processor.html * Support for WSDL to Java Bindings: Integrated support for Apache Axis Java code generation directly within the Stylus Studio Web Service Call Composer - learn more at: http://www.stylusstudio.com/web_services.html * XML Adapter API Enhancements: Seamless access to relational databases, EDI, flat files, and other legacy data from your XSLT stylesheets or XQuery expressions can be done using Stylus Studio's Java adapter components that are now easier to embed and offer even faster streaming data performance - learn more at: http://www.stylusstudio.com/deployment/ You can download Stylus Studio(r) 2006 Release 2 today here: http://www.stylusstudio.com/xml_download.html Sincerely, The Stylus Studio Team http://www.stylusstudio.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: alternate representations of collections in XMLBeans??
Tim,
I would recommend using the extensions,
otherwise modifying the generated code is definitely possible but missing even
a small thing would break the code.
Back to using extensions, if one wants to
store a state he can do it by using XmlBookmark which stays with the
xml entity even if moved. In your case the hash map should be stored on metadata
element.
Also the pre/post Set methods are called
every time the document is about to change, so youll get calls for all creation/modification/deletion
events, made through XmlObject interfaces. Modification through other interfaces
like XmlCursor or DOM will not trigger the calls to the pre/post Set methods.
Cezar
From: Tim Parker
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 28, 2006 1:11
PM
To: user@xmlbeans.apache.org
Subject: alternate representations
of collections in XMLBeans??
The XMLBeans representation of a collection (for something
with a maxOccurs GT 1) is a bit limiting... I'm looking to extend it to look
more like a Map interface... and I'm hitting some brick walls...
For discussion sake, I'll use a structure with three fields:
struct foo
{
int ID;
String name;
HashMap metadata;
}
The 'metadata' field contains arbitrary name/value pairs -
for simplicity we'll say 'name' and 'value' fields in the hashmap are always
strings...
The obvious (to me, at least)schema for this is
something like:
xs:complexType name=NVP
xs:sequence
xs:element name=Value
type=xs:string/
/xs:sequence
xs:attribute name=Name
type=xs:string/
/xs:complexType
xs:complexType name=NVPCollection
xs:sequence
xs:element name=Entry type=my:NVP
minOccurs=0 maxOccurs=unbounded/
/xs:sequence
/xs:complexType
xs:complexType name=testCase
xs:sequence
xs:element name=ID
type=xs:int/
xs:element name=name
type=xs:string/
xs:element name=metadata
type=my:NVPCollection/
/xs:sequence
/xs:complexType
I could build another layer on top of this, butthis
could get ugly- What I really need is a way to extend NVPCollection so I
can address items by name (like in a HashMap) rather than by position...
The ideal would be something like (assuming that we have a
mechanism to bind the 'name' field to the map key and the 'value' field to be
the one of interest)...
NVPCollection thisCollection;
// some magic here to get the collection populated...
someValue =
thisCollection.GetByMap(someArbitraryName);
Or we could save some binding complexity by doing
...GetByMap(someArbitraryName,value), saying get
the field 'value' from the collection member whose key fieldcontains
'someArbitraryName' (The presumption is that the binding to the key field
'name' would need to be established earlier so the map can be maintained)
As I read the documentation, I could build an extension like
this, but I'm hosed if I want to do anything more sophisticated than a linear
search through the collection on each 'get' call - Unless I'm missing
something, I need a place to put an instance-specific HashMap object to
maintain mapping between the key field ('name') and the array index... more
than a little difficult with the 'static method' requirement for the
extension (Not to mention the population problem for the HashMap object
itself, but a preSet or postSet implementation would work as long as I never
try to delete anything)..
Presumably I could also build an 'extendedNVPCollection'
class, based on the NVPCollection class generated by XMLBeans, but how would I
wire that back into my (XMLBeans-generated) 'testCase' class? I don't
want to get into creating wrapper classes for every layer...
I tried ignoring thedon't touch - generated
code warningsand added some stuff directly to the generated classes
for the NVPCollection object, but things started breaking- I'm not sure
if the problem is a flaw in my hacking or a fundamental problem I won't solve,
so I'm seeking advice -am I tilting at windmills here?
Does anyone have ideas as to better ways to do this?
===
Tim
Parker
Senior
Developer
PaperThin,
Inc.
617-471-4440
x 203
[EMAIL PROTECTED]
www.paperthin.com
===
PaperThin,
Inc. was recently named to KMWorlds 100 Companies that Matter in
Knowledge Management.
Find out
more at www.paperthin.com.
___
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and
RE: alternate representations of collections in XMLBeans??
Thank you for the quick reply - I'll look into the
XMLBookmark idea...
Is there anything else I need to know about the preSet and
postSet methods? I found documentation (including the operationType
values) at http://dev2dev.bea.com/pub/a/2004/11/Configuring_XMLBeans.html-
is this the latest-and-greatest, or is there a better and/or more current
reference available?
Tim
From: Cezar Andrei [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 28, 2006 2:29 PMTo:
user@xmlbeans.apache.orgSubject: RE: alternate representations of
collections in XMLBeans??
Tim,
I would recommend using
the extensions, otherwise modifying the generated code is definitely possible
but missing even a small thing would break the
code.
Back to using
extensions, if one wants to store a state he can do it by using XmlBookmark
which stays with the xml entity even if moved. In your case the hash map should
be stored on metadata element.
Also the pre/post Set
methods are called every time the document is about to change, so youll get
calls for all creation/modification/deletion events, made through XmlObject
interfaces. Modification through other interfaces like XmlCursor or DOM will not
trigger the calls to the pre/post Set methods.
Cezar
From: Tim
Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 1:11
PMTo:
user@xmlbeans.apache.orgSubject: alternate representations of
collections in XMLBeans??
The XMLBeans representation of a
collection (for something with a maxOccurs GT 1) is a bit limiting... I'm
looking to extend it to look more like a Map interface... and I'm hitting some
brick walls...
For discussion sake, I'll use a
structure with three fields:
struct
foo
{
int
ID;
String
name;
HashMap
metadata;
}
The 'metadata' field contains
arbitrary name/value pairs - for simplicity we'll say 'name' and 'value' fields
in the hashmap are always strings...
The obvious (to me, at
least)schema for this is something
like:
xs:complexType
name="NVP"xs:sequencexs:element
name="Value"
type="xs:string"//xs:sequencexs:attribute
name="Name"
type="xs:string"//xs:complexType
xs:complexType
name="NVPCollection"xs:sequencexs:element
name="Entry" type="my:NVP" minOccurs="0"
maxOccurs="unbounded"//xs:sequence/xs:complexType
xs:complexType
name="testCase"
xs:sequence
xs:element
name="ID" type="xs:int"/
xs:element
name="name" type="xs:string"/
xs:element
name="metadata" type="my:NVPCollection"/
/xs:sequence
/xs:complexType
I could build another layer on top
of this, butthis could get ugly- What I really need is a way to
extend NVPCollection so I can address items by name (like in a HashMap) rather
than by position...
The ideal would be something like
(assuming that we have a mechanism to bind the 'name' field to the map key and
the 'value' field to be the one of
interest)...
NVPCollection
thisCollection;
// some magic here to get the
collection populated...
someValue =
thisCollection.GetByMap("someArbitraryName");
Or we could save some binding
complexity by doing ...GetByMap("someArbitraryName","value"), saying "get the
field 'value' from the collection member whose key fieldcontains
'someArbitraryName'" (The presumption is that the binding to the key field
'name' would need to be established earlier so the map can be
maintained)
As I read the documentation, I could
build an extension like this, but I'm hosed if I want to do anything more
sophisticated than a linear search through the collection on each 'get' call -
Unless I'm missing something, I need a place to put an instance-specific HashMap
object to maintain mapping between the key field ('name') and the array index...
more than a little difficult with the 'static method' requirement for the
extension (Not to mention the population problem for the HashMap object
itself, but a preSet or postSet implementation would work as long as I never try
to delete anything)..
Presumably I could also build an
'extendedNVPCollection' class, based on the NVPCollection class generated by
XMLBeans, but how would I wire that back into my (XMLBeans-generated) 'testCase'
class? I don't want to get into creating wrapper classes for every
layer...
I tried ignoring the"don't
touch - generated code" warningsand added some stuff directly to the
generated classes for the NVPCollection object, but things started
breaking- I'm not sure if the problem is a flaw in my hacking or a
fundamental problem I won't solve, so I'm seeking advice -am I tilting at
windmills here?
Does anyone have ideas as to better
ways to do this?
===
Tim
Parker Senior Developer
PaperThin, Inc.
617-471-4440 x 203
[EMAIL PROTECTED]
www.paperthin.com
===
PaperThin, Inc. was recently named
to KMWorlds 100 Companies that Matter in Knowledge Management.
Find out more at www.paperthin.com.
RE: alternate representations of collections in XMLBeans??
That is a good article to read, also check
out the tests under test\cases\xbean\extensions.
Cezar
From: Tim Parker
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 28, 2006 3:08
PM
To: user@xmlbeans.apache.org
Subject: RE: alternate
representations of collections in XMLBeans??
Thank you for the quick reply - I'll look
into the XMLBookmark idea...
Is there anything else I need to know
about the preSet and postSet methods? I found documentation (including
the operationType values) at http://dev2dev.bea.com/pub/a/2004/11/Configuring_XMLBeans.html-
is this the latest-and-greatest, or is there a better and/or more current
reference available?
Tim
From: Cezar
Andrei [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 28, 2006 2:29
PM
To: user@xmlbeans.apache.org
Subject: RE: alternate
representations of collections in XMLBeans??
Tim,
I would recommend using the extensions,
otherwise modifying the generated code is definitely possible but missing even
a small thing would break the code.
Back to using extensions, if one wants to
store a state he can do it by using XmlBookmark which stays with the
xml entity even if moved. In your case the hash map should be stored on
metadata element.
Also the pre/post Set methods are called
every time the document is about to change, so youll get calls for all
creation/modification/deletion events, made through XmlObject interfaces.
Modification through other interfaces like XmlCursor or DOM will not trigger
the calls to the pre/post Set methods.
Cezar
From: Tim Parker
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 28, 2006 1:11
PM
To: user@xmlbeans.apache.org
Subject: alternate representations
of collections in XMLBeans??
The XMLBeans representation of a collection (for something
with a maxOccurs GT 1) is a bit limiting... I'm looking to extend it to look
more like a Map interface... and I'm hitting some brick walls...
For discussion sake, I'll use a structure with three fields:
struct foo
{
int ID;
String name;
HashMap metadata;
}
The 'metadata' field contains arbitrary name/value pairs -
for simplicity we'll say 'name' and 'value' fields in the hashmap are always
strings...
The obvious (to me, at least)schema for this is
something like:
xs:complexType name=NVP
xs:sequence
xs:element name=Value
type=xs:string/
/xs:sequence
xs:attribute name=Name
type=xs:string/
/xs:complexType
xs:complexType name=NVPCollection
xs:sequence
xs:element name=Entry type=my:NVP
minOccurs=0 maxOccurs=unbounded/
/xs:sequence
/xs:complexType
xs:complexType name=testCase
xs:sequence
xs:element name=ID
type=xs:int/
xs:element name=name
type=xs:string/
xs:element name=metadata
type=my:NVPCollection/
/xs:sequence
/xs:complexType
I could build another layer on top of this, butthis
could get ugly- What I really need is a way to extend NVPCollection so I
can address items by name (like in a HashMap) rather than by position...
The ideal would be something like (assuming that we have a
mechanism to bind the 'name' field to the map key and the 'value' field to be
the one of interest)...
NVPCollection thisCollection;
// some magic here to get the collection populated...
someValue =
thisCollection.GetByMap(someArbitraryName);
Or we could save some binding complexity by doing
...GetByMap(someArbitraryName,value), saying get
the field 'value' from the collection member whose key fieldcontains
'someArbitraryName' (The presumption is that the binding to the key field
'name' would need to be established earlier so the map can be maintained)
As I read the documentation, I could build an extension like
this, but I'm hosed if I want to do anything more sophisticated than a linear
search through the collection on each 'get' call - Unless I'm missing
something, I need a place to put an instance-specific HashMap object to
maintain mapping between the key field ('name') and the array index... more
than a little difficult with the 'static method' requirement for the extension
(Not to mention the population problem for the HashMap object itself, but a
preSet or postSet implementation would work as long as I never try to delete
anything)..
Presumably I could also build an 'extendedNVPCollection'
class, based on the NVPCollection class generated by XMLBeans, but how would I
wire that back into my (XMLBeans-generated) 'testCase' class? I don't
want to get into creating wrapper classes for every layer...
I tried ignoring thedon't touch - generated
code warningsand added some stuff directly to the generated classes
for the NVPCollection object, but things started breaking- I'm not sure
if the problem is a flaw in my hacking or a fundamental problem I won't solve,
so I'm seeking advice -am I
XMLBookmark question...
As a follow-on to the HashMap implementation
questions... I feel like I may be missing something but... I'm looking at
creating an extension methodfor my NVPCollection class something
like:
public String getValueByMap(String
keyName)
If I hang the hashmap on a bookmark, how do I get the
bookmark without having to do a newCursor() every time? Or is it OK to run
newCursor() dozens or hundreds of times without risk of performance or memory
problems? Am I missing something?
Tim
From: Cezar Andrei [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 28, 2006 4:33 PMTo:
user@xmlbeans.apache.orgSubject: RE: alternate representations of
collections in XMLBeans??
That is a good article
to read, also check out the tests under
test\cases\xbean\extensions.
Cezar
From: Tim
Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 3:08
PMTo:
user@xmlbeans.apache.orgSubject: RE: alternate representations of
collections in XMLBeans??
Thank you for the quick
reply - I'll look into the XMLBookmark idea...
Is there anything else
I need to know about the preSet and postSet methods? I found documentation
(including the operationType values) at http://dev2dev.bea.com/pub/a/2004/11/Configuring_XMLBeans.html-
is this the latest-and-greatest, or is there a better and/or more current
reference available?
Tim
From: Cezar
Andrei [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 2:29
PMTo:
user@xmlbeans.apache.orgSubject: RE: alternate representations of
collections in XMLBeans??
Tim,
I would recommend using
the extensions, otherwise modifying the generated code is definitely possible
but missing even a small thing would break the
code.
Back to using
extensions, if one wants to store a state he can do it by using XmlBookmark
which stays with the xml entity even if moved. In your case the hash map should
be stored on metadata element.
Also the pre/post Set
methods are called every time the document is about to change, so youll get
calls for all creation/modification/deletion events, made through XmlObject
interfaces. Modification through other interfaces like XmlCursor or DOM will not
trigger the calls to the pre/post Set methods.
Cezar
From: Tim
Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 1:11
PMTo:
user@xmlbeans.apache.orgSubject: alternate representations of
collections in XMLBeans??
The XMLBeans representation of a
collection (for something with a maxOccurs GT 1) is a bit limiting... I'm
looking to extend it to look more like a Map interface... and I'm hitting some
brick walls...
For discussion sake, I'll use a
structure with three fields:
struct
foo
{
int
ID;
String
name;
HashMap
metadata;
}
The 'metadata' field contains
arbitrary name/value pairs - for simplicity we'll say 'name' and 'value' fields
in the hashmap are always strings...
The obvious (to me, at
least)schema for this is something
like:
xs:complexType
name="NVP"xs:sequencexs:element
name="Value"
type="xs:string"//xs:sequencexs:attribute
name="Name"
type="xs:string"//xs:complexType
xs:complexType
name="NVPCollection"xs:sequencexs:element
name="Entry" type="my:NVP" minOccurs="0"
maxOccurs="unbounded"//xs:sequence/xs:complexType
xs:complexType
name="testCase"
xs:sequence
xs:element
name="ID" type="xs:int"/
xs:element
name="name" type="xs:string"/
xs:element
name="metadata" type="my:NVPCollection"/
/xs:sequence
/xs:complexType
I could build another layer on top
of this, butthis could get ugly- What I really need is a way to
extend NVPCollection so I can address items by name (like in a HashMap) rather
than by position...
The ideal would be something like
(assuming that we have a mechanism to bind the 'name' field to the map key and
the 'value' field to be the one of
interest)...
NVPCollection
thisCollection;
// some magic here to get the
collection populated...
someValue =
thisCollection.GetByMap("someArbitraryName");
Or we could save some binding
complexity by doing ...GetByMap("someArbitraryName","value"), saying "get the
field 'value' from the collection member whose key fieldcontains
'someArbitraryName'" (The presumption is that the binding to the key field
'name' would need to be established earlier so the map can be
maintained)
As I read the documentation, I could
build an extension like this, but I'm hosed if I want to do anything more
sophisticated than a linear search through the collection on each 'get' call -
Unless I'm missing something, I need a place to put an instance-specific HashMap
object to maintain mapping between the key field ('name') and the array index...
more than a little difficult with the 'static method' requirement for the
extension (Not to mention the population problem for the HashMap object
itself, but a preSet or postSet implementation would work as long as I never try
to delete anything)..
Presumably I could
RE: Can I set noNamespaceSchemaLocation attribute (xmlbeans 1.0.4)
Actually, XmlBeans doesn't have specific APIs to deal with xsi:[noNamespace]schemaLocation attributes (maybe it should) You would have to set it as an ordinary non-Schema declared attribute, like that: XmlCursor c = root.newCursor(); c.insertAttributeWithValue(noNamespaceSchemaLocation, http://www.w3.org/2001/XMLSchema-instance;, yourValue); Radu -Original Message- From: Grant Lewis [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 6:46 AM To: XMLBeans List Subject: Can I set noNamespaceSchemaLocation attribute (xmlbeans 1.0.4) I'm actually stuck using version 1.0.3 bundled with weblogic 8.1. I'm calling a cold fusion web service that requires the noNamespaceSchemaLocation attibute be set on the root element of the request xml. Is there a way I can add the attribute to the root element before I call xmlText on the bean. Grant - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
