[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]