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
>
> <mailto:>
>
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670
