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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Update on CIQ Specs.- moving forward


Dear all,

CIQ Specs. is ready for moving to the next stage, i.e. public review.
I am waiting on some confirmation from OGC on address location
geocordinates profile. New Zealand Govt. is also assisting in this.

Over the weekend, I created empty code lists for all
attributes/elements that add semantics to the data and currently uses
string data type. The advantage of using this code list approach is
that, users who want to ensure strict interoperability, can customise
the code lists. Else, the attributes/elements data types that
reference code lists that do not have any value, will be treated as a
string by XML parsers. This provides an additional level of
flexibility and control to the users. Now CIQ has 90 code lists (10
for xNL, 25 for xAL, and 56 for xPIL). I converted all these code
lists into genericode and created the context/value association file
and everything works fine.

With this code list approach and with genericode approach as an
option, I am very confident that CIQ V3.0 is very powerful to deal
with any type of application  and irrespective of any industry. CIQ
V3.0 is powerful and yet, simple to implement. This is the beauty
about this specs. I am excited.

One of the past criticisms of CIQ has been that if you consider address schema,
because it is very rich in its structure due to its generic approach,
users find it too rich for their use case which could be only to have
few elements of xAL. Many talked about defining address templates for
countries that can be used to customise address structure to suit
specific country requirements.

In version 3.0, with the use of UMCLVV approach of genericode, users
can define business rules outside of the CIQ schema to customise the
CIQ schemas. What I have done now is included a sample example that
defines a business rule (one line of code using schematron pattern and
xPATH) on xAL to customise xAL schema to define an address structure
for Singapore that allows only 6 elements of xAL (Country, Locality,
Thoroughfare, Premises, Postal Delivery Point, and PostCode) and
ignores the use of the rest of the elements. I was overwhelmed by the
power of schematron to do this.

Though I have really slogged for the past couple of months in getting
the specs., ready, I am satisfied that the specs., has really come out
well. Thank you for all your guidance and support.

Please feel free to express your views.

Regards,

Ram


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]