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: Re: Update on CIQ specs moving forward


Ram

Many thanks for all your work.

And I particularly like this message!. don't lose it!  Add it to Section 2.12 of the Release Notes.  There's some great understanding in these words that need to be shared. 

Cheers
Colin
...........................................

"The overview 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]