|In schema, everything does NOT have to be defined as optional. CIQ chose that route to enhance its general reusability. So did NIEM. When building an exchange ( IEPD or not, CAM supported or not), you have the option of specificity via profiling (or "subset schemaing" which is a form of profiling) more generic standards. The issue below was caused because we did not profile CIQ. This left our more specific exchange as loosey-goosey as the standard which it chose to reuse. Tt is the easier route for the standard builder. It may or may not be the best route. (Our pending GML profile example shows that we have learned.)|
Bottom line, optionality is a choice and NOT A REQUIREMENT is schema.
On Mar 9, 2010, at 12:19 PM, David RR Webber (XML) wrote:
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
You are encountering the limitation of schema itself. Everything has to be defined as optional.
If you are following the NIEM IEPD approach - you would publish your IEPD and subset schemas as your profile.
The CAM toolkit provides full support for this.
Ingest the HAVE XSD into CAM template - tailor that as you desire - use excludeTree() rules to prune out pieces you don't need (to match EDXL conformance) - and then add other rules as desired to show dependencies on other parts that you do, and or your content restrictions. Then run File / Export / Compress process - to complete your template. You can then generate the subset schema, via File / Export / Template to XSD - to build either a flattened schema, or a NIEM compliant subset schema (depending on what type of application development tooling you are using).
You can also build the business documentation, XML examples, cross-reference to NIEM spreadsheet and NIEM wantlist - all as required for NIEM IEPD publishing.
This gives you a true complete profile of your use of EDXL HAVE, derived from the original OASIS schema.
Interoperability is then dependent on the conformance to that profile.
There is also the CAMV engine - which you can use in lieu of schema checks for production runtime. This has added benefit of providing graduated failure levels - error, warning, info - rather than the XSD which only has error. This allows you to tailor the runtime actions of your backend systems to respond to differences in XML instances. An upcoming Developerworks article will be covering this with an example use case.
-------- Original Message --------
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs.
From: "Dwarkanath, Sukumar - INTL" <Sukumar_Dwarkanath@sra.com
Date: Tue, March 09, 2010 10:08 am
To: "McGarry, Donald P." <email@example.com
The restrictions on using CIQ were considered to be business rules and the intention was not create a profile as far as I remember. I am not against creating a CIQ Profile but if we go down that path, we should consider requirements across the other standards such as EDXL RM, DE etc. We have dealt with this particular issue quite a few times and it is a balance – offering flexibility vs ensuring interoperability.
After spending some time doing some coding this weekend I noticed something that we may want to address:
1. HAVE uses xPil which in turn uses xAL and xNL
2. We included the full schemas for all of these referenced schemas on the OASIS page to download the standards.
I think the problem here is that when I went to implement this the documentation states that we are using a “profile” recommendation to limit the choices for xPil to “maximize interoperability”. It then goes on to state that <have:Organization> should have the sub-elements OrganizationInformation and OrginizationGeoLocation.
OrganizationInformation should have the sub-elements as defined in the CIQ standard:
It also states that we won’t use georss but will use the gml in the OrganizationGeoLocation Section.
It also refers me to Appendix C which suggests that I refer to the CIQ TC website, and also states that for the purpose of HAVE the naming & location elements are used. The use of other elements is left to implementation choices.
Conformance is defined in the document as:
1. Validating to the schema
2. Meets the mandatory requirements of section 3
My concern is that the referenced xPil schemas (and in turn the xAL and xNL) are the FULL SCHEMAS. There is no restriction in the HAVE schema enforcing our smaller profile of CIQ. Additionally the reference to the georss namespace or elements was not removed. Furthermore, the document is somewhat confusing in that it states what elements to use, but then tells the develop that it’s an implementation choice whether to use the other elements or not. Right now as it stands I can generate an XML document that has a bunch of xPIL fields that we didn’t include in our documentation, but will validate against our schemas. With the vagueness in the document I could argue that this was an implementation choice and my document is valid according to the conformance section, but I suspect my document may break some systems.
So which is it? If I am building an XML processor to ingest HAVE documents I need to know what to expect. If I need to be prepared to handle Accounts, Documents, Revenues, Stocks, etc. as defined in xPIL because some system out there decided that they wanted to do it, that makes HAVE more heavyweight that I think the designers intended. If indeed we are using a CIQ “profile” we should develop the schema for that profile and post it with the standard and add some more info to our documentation so it isn’t as vague. I’ll upload my generated sample file as HAVE_FullToSchemaButNotDocument.xml to the TC page so you can check it out. This example validated against the schemas from our page. I added in Geo-RSS as well (which will validate if you reference the georss schema)…