[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
I believe it does, Don, I'll have to double check, of course, but that's my memory of it. Cheers, Rex McGarry, Donald P. wrote: > Just an FYI...As I am writing more code today I'm noticing some questions regarding whether we intended to allow Lists for some of these contact information elements as well. I would be more than happy to head up any effort needed to clear this up. Does RM use the same CIQ "profile" as HAVE? > > -Don > Office: 315-838-2669 > Cell: 315-383-1197 > dmcgarry@mitre.org > > > -----Original Message----- > From: Rex Brooks [mailto:rexb@starbourne.com] > Sent: Monday, March 08, 2010 10:03 AM > To: McGarry, Donald P. > Cc: emergency@lists.oasis-open.org > Subject: Re: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas > > Excellent points, Don, > > Since this work was not done in a SC, we'll need to either work it in a TC meeting or see if we can call a special meeting for it. > > Cheers, > Rex > > McGarry, Donald P. wrote: > >> All- >> >> 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: >> >> * OrganisationName >> >> * OrganisationInfo >> >> * Addresses >> >> * ContactNumbers >> >> * CommentText >> >> 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)... >> >> Don McGarry >> >> Office: 315-838-2669 >> >> Cell: 315-383-1197 >> >> dmcgarry@mitre.org <mailto:dmcgarry@mitre.org> >> >> > > -- > Rex Brooks > President, CEO > Starbourne Communications Design > GeoAddress: 1361-A Addison > Berkeley, CA 94702 > Tel: 510-898-0670 > > > --------------------------------------------------------------------- > 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: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]