xNAL V3 Requirements/Implementation CW NZ

[colin.wallis@ssc.govt.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

2)	Removing attributes to support postal service codes from Basic is NOT covered but should be, in order to help integration with UBL etc
 
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.
 
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?  

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?

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.

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. 

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


-----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/xNAL%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.
> 
>