xNAL V3 Requirements/Implementation CW NZ

[colin.wallis@ssc.govt.nz]

Hi Max, 
My comments next to yours below.  I have deleted the extraneous bits of my previous post.
Cheers
Colin
-----Original Message-----
From: Max Voskob [mailto:max.voskob@paradise.net.nz]
Sent: Thursday, 17 March 2005 1:42 p.m.
To: ciq@lists.oasis-open.org
Subject: RE: [ciq] xNAL V3 Requirements/Implementation CW 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

1)	External namespace reference is covered in the Requirements
<MV> Colin, sorry, I'm not with you on this. Can you clarify what you mean by "External namespace reference"
<CW> The revised Requirements has the following notation "Wherever possible, provide the ability to refer to external namespace(s).  Example:  Codelist (enumerations), geocoding specs, etc".

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?
<CW> No we are not integrating with UBL. It was a poor choice of words by me.  Sorry. But we did look at and compare the structure of ebXML with CIQ.  We agreed that we did not want to align, but to quote Ram, " we can get rid of the attributes to support postal services codes and use namespace references instead".   

 
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.
<CW>  Great, 'cos WS-I should help us provide a framework for the Implementation too.
 
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.
<CW>  OK

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.
<CW> OK

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.
<CW> We might be able to use student-power during the university vacation as per the UMLs, but beyond that it's tight. 

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.
<CW> We have not progressed too far due to $$. We did an XSLT for xNAL V2 to xNAL nz but beyond that nothing yet.  We want to use open source where possible (e.g. WS-I) to minimise $$, mtance, etc.  But it is still possible and could be leveraged.     

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.
<CW>  You are correct. Hopefully we can extend xCIL if and where needed for whatever element set is agreed.  Implementation needs to be agreed. Working Groups are commencing soon and I expect there to be an opportunity for "expert advice" and  to a limited (read non capital) extent, tools:-). 


-----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