RE: [ciq] xNAL V3 Requirements/Implementation CW NZ

["Max Voskob" <max.voskob@paradise.net.nz>]

 Hi Colin,

See my comments inline

Cheers,
Max

-----Original Message-----
From: colin.wallis@ssc.govt.nz [mailto:colin.wallis@ssc.govt.nz] 
Sent: Thursday, 17 March 2005 11:05 a.m.
To: ciq@lists.oasis-open.org
Subject: [ciq] xNAL V3 Requirements/Implementation CW NZ

Dear CIQ 

Last month I extracted the threads that were running on this and tried to bring them to a conclusion
about what is/should be in/out of the xNAL V3 Requirements.

Unfortunately, they don't appear to have got through to you..or you found the proposal so ghastly
you couldn't bring yourselves to respond!:-) I sent them from my email and not from the OASIS site.
Sorry.  

1)	External namespace reference is covered in ther Requirements
<MV> Colin, sorry, I'm not with you on this. Can you clarify what you mean by "External namespace
reference"

2)	Removing attributes to support postal service codes from Basic is NOT covered but should be,
in order to help integration with UBL etc

<MV> Are integrating with UBL? Did I miss something?
 
2a) 	##any Elements is out as agreed, but we still have no agreement on ##any Attributes. Max
says we need to provide extensibility and NZ agrees, but Hido says this is not the best way to do
it.  Maybe not, but what is?  We think an example of using ##any attribute would be if the a schema
user wanted to use an attribute "Derivation" to further describe a personname "Andrew" from the
Greek word "manliness".  The Specs would have to be very specific about the restrictive use of this
attribute..otherwise it could be abused. The bigger question is "do we have a good design for
extensibility?"  If we agree ##any attribute is the best we can do, then it goes in. If not it stays
out.

<MV> This needs some additional considerations. I'm reviewing WS-I basic profile 1.1 at the moment.
It may give us some clues on what's the best option here.
 
3)	Implementation Guide: Definitely needed, we all agree. But there are so may ways of cutting
this.  One is by  "profile" ..offering Profile options for different user needs for xNAL.  A profile
(NZ's is one option here but would need reworking to work in V3), a potential Courier/FEDEX profile.
A second is to offer Implementation advice on CAM/Schematron/Mapforce? for content mapping, Hido's
Java objects for interrogating data (get/set routines).  A third is basic Guidance on a Web Services
implementation (where to use WSI, on top of/rather than OASIS WS Standards, pointers to WSE2 if the
user is on a Microsoft platform or Java tools (are there any yet?) if the user is on a non MS
platform. A fourth could be a Best Practice checklist for parties involved in XML data exchange (NZ
has one in draft I'd be happy to share and extend). 

4) I think we need to add Referencing to our requirements.  XML is bulky enough without repeating
all the code for every record.  Max did some referencing conventions for the xNAL NZ profile in
Chapter 7. 

http://www.e-government.govt.nz/docs/xnal-guidelines-1-0/index.html

Could we re-use those?  

<MV> referencing is a tricky one. Useful, but is unlikely to be used in practice. I'd rather leave
it out.


5)	Identifiers - There is an Identifier (ID as I recall it, to make it compatible with UBL?)
but I don't think it is in the same context as Max proposed in the xNAL NZ profile.  Max (correct me
if I'm wrong here Max)had the ID structured in a kind of tree format, in that it was formed from a
series of sub parts. The idea was that if you had a national address identifier model built from
location, street number etc you could build and extend an identifier for each address or location.
The identifier would then be the linkage used by all users of address data to link, say a geocode, a
mesh block, a survey/legal description, a delivery/atttendence address etc. Explain the
circumstances that you use them (e.g. implementing a single or national address file) and emphasise
they require significant external support to manage change control, versioning, etc 
Is there any value in giving guidance on identifiers?

<MV> Again, looks nice on the surface, but is not practically applicable on a wider scale, unless we
specify what those IDs mean which will be too restrictive, so it's a catch 22.

What I am getting at is "impementation" is a many sided beast...it can mean "implementing it in my
environment..and making a profile, while ensuring I do not break the W3C rules and still can
interpret other xNAL profiles".  And it can also mean "how do I actually do it in a web service?, in
a file transfer?, in a ..whatever.

<MV> Colin, I think that answering those questions is useful, but is low priority, unless someone
can provide a resource to write it all up.

If we did all this then I think there is a better chance that we get a greater take up of the
standard and more consistency. I know it is a fine line how much we prescribe and how much we leave
flexible. But now is the time we have to put our stakes in the ground, decide for better or worse
and get on with it. 

<MV> the take up is not going to happen unless there are tools, no matter what the scale is. I
understand you were doing some work in this area. Would be very interesting to know what was the
outcome and if it can be leveraged.

I think we should also release a Draft first, so we can get more feedback on what is missing.  There
are probbaly some implementations going on that we don't know about.

Cheers

Colin  

PS: FYI: NZ has an all-of-government authentication project underway which will use xCIL (probably
V2 unless V3 gets going soon) which needs to integrate with RSA software and SAML1.1. We need to
have the trial underway by November so the clock is ticking). 

<MV> That's interesting. I don't think there will be any problems encrypting or signing an  xCIL or
any other XML document, if this is what you mean by RSA software. Please correct my understanding if
I'm wrong here.




-----Original Message-----
From: Ram Kumar [mailto:kumar.sydney@gmail.com]
Sent: Thursday, 24 February 2005 11:16 a.m.
To: Max Voskob
Cc: ciq@lists.oasis-open.org
Subject: Re: [ciq] xNAL requirements


Max,
Please find enclosed the revised requirements with my comments. 

CIQ TC,
Pease contribute to the requirements.
I do not see any major changes to the requirements and we have already looked into it before
starting our work on the specs. But as Max has pointed out, it is always better to keep re-visiting
our requirements.
So, please contribute.

BTW, I have not got any contributions from CIQ TC on the implementation consideration chapter of the
specifications document.
Please contribute. Thanks.

Regards,

Ram


On Thu, 24 Feb 2005 07:12:54 +1300, Max Voskob <max.voskob@paradise.net.nz> wrote:
> Hi all,
> 
> I'd like to renew the discussion about xNAL requirements
> 
> Please, review
> http://www.oasis-open.org/apps/org/workgroup/ciq/download.php/1517/xNA
> L%203%20Requirements.doc
> 
> and post your comments or change the document (with track changes on)
> 
> We really need to sort out requirements to make any progress here.
> 
> Cheers,
> Max
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ciq/members/leave_workgroup.php.
> 
>