OAG Canonicals

, ,
21

Hi Jessica,

In OAGIS, a customer is a subtype of ‘Contact’.

Take a look at Components.xsd

Regards

22

Correction…

In OAGIS 7, customer is a subtype of ‘Partner’ (for example, ‘ShipTo’).

In OAGIS 8, customer is a subtype of ‘Party’ (for example, ‘ShipToParty’).

23

Did any one try using OAGIS 9.0.
I am trying to install document type in webMethods 6.1
but i cant it asking for dependable XSD which is already in the folder.
I am using process_purchase_order.xsd schema.

is OAGIS is better then other canonicals ?

any help is highly appreciated

24

Hi kk - Your question about whether OAGIS is a better standards body than others is a rather tough one to answer. As for your first point, could it be that the BOD that you’re loading into Developer requires support for recursive XML elements? Unless that has changed since 12/2004, wM doesn’t allow you to load XML schemas that have recursive elements.

  • Rajesh
25

Thanks Rajesh & Alan,

I am trying to load process purchase order.xsd and webMethods could not compile giving me following error …

Couldn’t compile

com.wm.util.LocalizedException: [ISC.0082.9805] The system cannot find Resources\Components\CoreComponents\UnqualifiedDataTypes.xsd

I already have Resource folder and there is UnqualifiedDataTypes.xsd present exactly same folder structure as we see in the Error.
Is there any way to resolve this dependencies?

Thanks a lot.

26

Alan,
Issue #1 and #2 should only surface after converting an XML tree to an IData, which is a much simplier data structure than an XML DOM - one that although far from perfect, is good at modeling XML, EDI, FlatFile, DBMS and other kinds of data. I believe the deficiencies you correctly note can be avoided:

  1. You should be able to validate the XML parse tree (the “node” object) against it’s schema before converting to an IData. If there are XSD constructs not correctly supported against the parse tree, they should be reported as bugs.

  2. When converting to an IData there are options to documentToRecord to retain order as defined in #2. The default behavior is to roll up duplicate elements into an array because that is a convienent data structure to work with and most documents do not have implied semantics based on multiple-element ordering (I would go as far as saying a document that does is legal based on an XSD, but poorly defined. An example of this poor design is in the flow.xml file format. If I only knew six years ago what I know now, I could simplify the flow loader. ;-)). Also queryDocument can be used to pull out the order dependent elements into an IData format that retains the ordering.

kk,

I did see a package of OAG schemas already imported here:
[url=“http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1611998181”]http://advantage.webmethods.com/cgi-bin/advantage/main.jsp?w=0&targChanId=knowledgebase&oid=1611998181[/url]
but I do not know if it specifically has the PO in it. The problem you are experiencing is because of a bug with the webM XSD parser handling multiple levels of relative XSD import paths. The current working directory was not reset after the first import, therefore, when the second file imports a third XSD the relative path was resolved based on the first XSD’s directory, which breaks when there are lots of imports in the complex directory structure OAG ships with. This package was created by re-orging the directory tree. I’m not sure if this bug is fixed in the Integration Server 6.5 release.

Cheers,
Fred