[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
|
Don, 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. Sukumar From: McGarry, Donald
P. [mailto:dmcgarry@mitre.org] 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]