[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ciq] 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]