RE: [ciq] RE: IMPORTANT - Your suggestions please

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

From a lifecycle perspective, does altering the software to recognize 3.1
(either instead of or in addition to 3.0) consume more effort than your
proposal of having people (and software) remember when to apply the errata?

It certainly would seem cleaner to bundle everything as 3.1.


					Fulton Wilcox
					Colts Neck Solutions LLC



-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info] 
Sent: Tuesday, March 11, 2008 11:23 AM
To: fulton.wilcox@coltsnecksolutions.com
Cc: mary.mcrae@oasis-open.org; kumar.sydney@gmail.com;
ciq@lists.oasis-open.org
Subject: RE: [ciq] RE: IMPORTANT - Your suggestions please

Fulton,

I don't think its that simple.  The 3.0 is already out there for xAL - so
the errata needs to be applied to that as a separate task - and those schema
changes posted there.

Changing the namespace will cause existing SW to fail.

Best to leave the namespace same - just update the schema.

I think we're OK - so long as we separate the two sets of changes - and just
note that for the xPRL there's a need to use the xAL with errata applied.
(Aside - also that errata will only effect a small number of people).

DW

> -------- Original Message --------
> Subject: RE: [ciq] RE: IMPORTANT - Your suggestions please
> From: Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>
> Date: Tue, March 11, 2008 9:16 am
> To: kumar.sydney@gmail.com,  ciq@lists.oasis-open.org
> Cc: mary.mcrae@oasis-open.org
> 
> Ram,
> 
> Despite impact on present adopters, it would seem that folding the errata
> corrections into a 3.1 is the better way. At some point that merging is
> necessary, and sooner probably is better than later.
> 
> If the only change that present adopters face is changing namespaces in a
> strictly mechanistic way (every reference to version 3 becomes 31) the
> impact on project costs and timelines would seem to be modest. 
> 
> If instead they are substantively affected by the corrections and have to
> alter what they have already implemented to accommodate the errata
changes,
> probably they (and later adopters) are better off. There is always the
risk
> that "errors" end up being set in concrete and become the new "truth."
> 
> 
> 						Fulton Wilcox
> 						Colts Neck Solutions LLC
> 
> 
> 
> -----Original Message-----
> From: kumar.sydney@gmail.com [mailto:kumar.sydney@gmail.com] 
> Sent: Tuesday, March 11, 2008 12:29 AM
> To: ciq@lists.oasis-open.org
> Cc: mary.mcrae@oasis-open.org
> Subject: [ciq] RE: IMPORTANT - Your suggestions please
> 
> Team,
> 
> If we do option 2, this could be a problem as the namespaces of the
schemas
> have to be changed from urn:oasis:names:tc:ciq:xnl:3 to
> urn:oasis:names:tc:ciq:xxx:31. I do not want this to happen as it will
> impact the current implementers of V3.0. This is NOT the IDEAL solution
and
> it looks ugly. I also need to change all original v3.0 documents that do
not
> discuss xPRL to now discuss about xPRL. 
> 
> The introduction of xPRL should not have any impact on current users
except
> xAL schema errata. 
> 
> Releasing xPRL v3.0 on its own looks good except that I do not know how to
> release the xAL v3.0 schema errata. Any release of xAL V3.0 schema errata
on
> its own is not possible. It has to go with V3.1 release of the original
V3.0
> specs. If we have had individual specs. for xNL, xAL, xNAL and xPIL (like
in
> v2.0), we could have release V3.1 xAL specs. that covers the errata. 
> 
> Therefore, I am confused. Not sure how to approach this problem!
> 
> Regards,
> 
> Ram
> ------------------------------
> TC Members,
> 
> OASIS TC Admin have come back to my request for 60 days public review of
> xPRL V3.0. As per TC process, only the following can be done:
> 
> - Release V3.1 (of November 2007 release) with xAL errata fix for 15 days
> public review
> 
> or
> 
> - Package xPRL V3.0 and xAL errata as part of a new version of CIQ
(Version
> 3.1 and includes specs. released in Nov. 2007) for 60 days public review
> 
> Please let me know your suggestions. Looks like the later is better.
> 
> Thanks 
> 
> Regards,
> 
> Ram
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php