OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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]