[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: CIQ discussion threads on CIQ/xNAL V3
Hi all We have had a number of discussions going recently and I wanted to see if we are at a point of reaching a conclusion? Some of these points may have a bearing on the draft V3 xNAL schema and docs that Ram has circulated. To this end, below, I have tried to identify the issue, fragments of the discussion thread with what I believe we are agreed on, and a view as to whether we have covered it in the V3 xNAL draft docs and schema (where applicable). Bear with me 'cos I am not deeply technical!!!!!! At this point, this does not include the recent discussion on parsers/validators as, while interesting, is only potentially relevant to the V3 docs in the Implementation section which Ram has asked for more input and the we will respond separately to. Issue 1) Alignment with UBL etc (CIQ Structure vs. CCTS et al) Thread: David, Do you have any views? By moving CIQ to align with ebXML CC is completely re-defining the goal of CIQ TC which is to be application independent. ebXML/UN CEFACT CC in the current form can never support party name and address application requirements and probably will ever. if they look at UPU, USPS, CEN Postal organisation requirements, they will understand why. This is my view. We can get rid of the attributes to support postal services codes and use namespace references instead. That is fine. But, what about the other attributes that are required to ensure that no original data (eg. separators, indicators, locators, etc) is lost when represented in xNAL? Ram Conclusion: Looking at the xNAL V3 docs it appears Ram has retained separators, but there is no mention of removing the attributes to support postal services and using namespace references. I think we are agreeing that we do this as it will assist in integrating other standards like UBL, while not really losing anything and also make it simpler. So that will need changing in the schema and the docs. (See Issues 4 and 5 are related but on a different thread). Issue 2) Creation of CAM templates to augment CIQ schemas and strong data typing Thread: Hido, Thanks! There's always a first for everything I guess!! I'll settle for 95% stable stuff and tweaking the 5% for those pesky boundary conditions. I've been deploying these scripting engine based solutions for too many years - so its just second nature at this point. Bring on the XML! DW. David, Thanks for reminding me. I've had a look at your work and I must say it looks impressive. I must give it a go next time I need to implement an XML standard! I am yet to work on a non-proprietary data standard where there was no need to change anything. Regards, Hido Hido, I would also point out - even though I've not started this task yet - that creating CAM templates to augment the CIQ schemas - allows you to custom select all those detail application binding details. I presented on CCTS + CAM + Registry to DHS on Friday - and listed CIQ as a component technology. The PPT and examples are here: http://drrw.net/CAM/presentations/Overview%20of%20CCTS%20and%20CAM%20and%20Registry%20PPT.zip Enjoy, DW p.s. One of these weeks life will stop intervening and I'll actually get to doing a specific CIQ example! Hopefully these slides here give hints, examples and ideas in the meantime. Hi Stephen I've encountered this problem a few times in the past while implementing not only CIQ, but some other standards as well. Normally strong typing is best left to the implementation. You'll always need to tweak the schema a little bit to fit your requirements, be it the Java binding library you're using, various flavours of parsers etc. I, for example, had to combine all CIQ schemas into one in order to implement it in webMethods! Perhaps it would be interesting to have versions of CIQ schemas ready for implementation for different platforms/libraries (eg .NET, XMLBeans, webMethods, whatnot). Having said this, I would be hesitant of putting any of these implementation specifics into the standard itself. This is the main reason why there are no strong-typed elements in the standard itself so far. As far as upgrading to future versions of the standards, there always changes you will have to implement anyway. If you stick to a consistent data typing approach, you'll minimise your migration headaches. This is definitely not a purist approach, but a practical and pragmatic one borne out of necessity in dealing with lots of different tools and libraries out there. Regards, Hido Hasimbegovic -------------------------------------------------------------------------------- Hi Stephen, Thank you for your detailed email. Yes, this is a problem with V2.0 and it is already in our list of things to do. The future versions of CIQ will be strongly data typed. Regards, Ram Conclusion: The V3 xNAL docs refer to V3 as strongly typed. Hido, are you ok with this given all the factors at play? We have not mentioned CAM in the xNAL V3 Docs Implementation section. But are we ballsy enough to explicitly state CAM as an option to assist Implementation and provide details on where and why it is useful? (Ideally David would need to do the work and test it before it enters the documentation). Is it worth holding off any release of V3 and the doc until DW has done his bit?) I know these two subjects are a bit "apples and pears" but strong data typing potentially reduces work in the implementation phase. CAM looks like it reduces work in the implementation phase in some circumstances as well, such as when you are integrating two standards or mapping from proprietary dbs to CIQ (there are others as well, I'm sure). Issue 3) Geospatial information Thread: CIQ TC, I have been looking at Geospatial information to support address data in xAL Advanced. The option I have come up with is to provide a choice to users, i.e. the ability to choose to use either the existing geocoding elements that we have in xAL or use the namespace of GML language. Ram CW's/NZ E-govt Unit view: We agree with Ram's view. We would like the Geocoding elements to be represented in GML. Why 're-invent' XML for geospatial elements?. The World already has internationally recognised schemata for encoding the geometry of a geographic feature - describing its location, shape or extent ( this could encompass an addressed feature - a dwelling, property, whatever ). ISO has adopted GML as the ISO 19136 standard. We do not see CIQ adds any value in developing their schema for geocoding when http://www.opengeospatial.org have already done with GML. On the other hand, there is an argument for giving the worldwide user base of CIQ some confidence with experimenting with basic geocoding elements, as an option. Hence our agreement with Ram. Conclusion: Is still required as I have not seen any more discussion on this. Does anyone disagree with Ram's view? Issue 4) Removing Postal Attributes from Basic (relates to Issue 1) Thread: I am also looking into simplifying xNL and xAL V3.0 "Basic" further by removing the postal services attributes namely element code and element code type from "Basic" version and move these sort of special attributes to "Advanced Version". Ram CW's/NZ E-govt view: We also feel that it wouldn't hurt to see 'Code' and 'CodeType' attributes banished from the basic schema, as they provide more 'advanced' metadata, not basic. Conclusion: Is still required, but does anyone disagree with Ram's view? (See Issue 1 above) Issue 5) Separate Namespaces for Basic and Advanced: I am also looking into seeing whether the "Basic" and "Advanced" versions can be kept separate with different namespaces rather than importing "Basic" into "Advanced". By this way, users can use "Basic" or "Advanced" or mix and match reusable elements. If different namespace support makes it complex, we still would like to keep "Basic" and "Advanced" separate rather than "Advanced" importing "Basic". By this way, all the complexities will be handled by "Advanced" and "Basic" can be made as simple as possible for user implementation. The whole objective of the above exercise is to keep "basic" as simple as possible as it is the one that will be widely used by users for various applications whereas, "Advanced" will be used for specialised applications such as data quality, matching, parsing, validation, etc. Ram CW's/NZ E-govt view As far as keeping the namespaces separate, care should be taken. We feel that we should reuse namespaces wherever possible. Users can benefit by seeing a relationship between xNAL basic and advanced, and how the advanced schema 'extends' the basic one. Separating this out could result in error and incompatibilities between the schemas, from a modelling perspective this would also be a nightmare, as it would make the high-level models for Advanced xNL, xNAL, xAL even more cluttered. Conclusion: Is still required, but currently the namespaces are NOT separate. Colin Wallis Senior e-GIF Business Analyst e-Government Unit - State Services Commission T: 04 495 6758 http://www.e.govt.nz
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]