Re: [ubl-ndrsc] NDR Checklist check

[Anne Hendry <anne.hendry@sun.com>]

Hi Mark,

Yes, I agree having two lists is not a good idea, if the two lists are 
duplicates.
However, the current list the ndr is keeping is a working document. 
 There is
currently no list that I'm aware of that is the list of the end result 
of ndr rules
discussions that LC can use.  So I am attempting to pull from the working
document something that can be more easily used by LC.  It's not so 
important
to me who keeps the list.  My action was to satisfy the need to identify 
clearly
(not within a changing working document) which rules have completed their
review/updating.   The main question that needs to be answered is:

>Does NDR agree that this list accurately represents rules that have been 
>	completed/finalized?
>
That would be very helpful.  Then we need a process for giving to LC 
rules as
they become finalized, since I think it's not feasible to wait for the 
entire review
to complete before handing the list over.

Thanks,
Anne

CRAWFORD, Mark wrote:

>Anne,
> 
>As always I am hesitant to have multiple lists.  I would prefer that we maintain one list for our work that is also available to LCSC.  
> 
>Mark
>
>	-----Original Message----- 
>	From: Anne Hendry [mailto:anne.hendry@sun.com] 
>	Sent: Mon 6/30/2003 2:53 PM 
>	To: ubl-ndrsc@lists.oasis-open.org 
>	Cc: 
>	Subject: [ubl-ndrsc] NDR Checklist check
>	
>	
>
>	Hi, 
>
>	In the TTSC meeting this morning there was some discussion about the 
>	status of the ndr rules.  It was acknowledged that, using the latest 
>	checklist as posted to the ndr site on 25 June, the rules that have the 
>	word 'ACCEPTED' in the 'Comment' column could be considered to be 
>	completed by NDRSC (reviewed/voted/decided) and stabilitzed to the point 
>	that LCSC can go ahead and implement these without concern about further 
>	NDRSC changes (unless LCSC or TTSC finds problems with implementing or 
>	needs additional clarification).  So to make it a bit easier to identify 
>	these, and to make sure we're agreed on this, I've gone ahead and pulled 
>	out from the NDR Checklist the rules that have the word 'ACCEPTED' in the 
>	'Comment' column.  They are: 
>
>
>	NDR Rule # 
>	NDR Rule Text 
>	25 June 2003 NDR 'ACCEPTED' 
>	(from UBL Schema Naming and Design Rules Checklist_20030625.rtf as 
>	posted to ndr site) 
>	[R1] 
>	All UBL schema design rules MUST be based on the W3C XML Schema 
>	Recommendations: XML Schema Part 1: Structures and XML Schema Part 2: 
>	Datatypes. 
>	ACCEPTED. 
>	[R3] 
>	Each dictionary entry name must define one and only one fully qualified 
>	path (FQP) for an element or attribute. 
>	ACCEPTED. 
>
>	CK: Seems to suggest that dictionary entry name use XPath, but then 
>	current usage of dictionary entry name doesn't do that.  So which is which? 
>	[R4] 
>	Names must be in the English language, using the primary English 
>	spellings provided in the Oxford English Dictionary. 
>	ACCEPTED. 
>	[R8] 
>	Names must be in singular form unless the concept itself is plural 
>	(example: Goods). 
>	ACCEPTED. 
>
>	CK: Please define a measure of "clarity". 
>	[R9] 
>	Upper-camel-case (UCC) MUST be used for naming elements and types. 
>	ACCEPTED. 
>
>	Standards document that describes the Upper and Lower case, we need 
>	reference there. 
>	[R10] 
>	Lower-camel-case (LCC) MUST be used for naming attributes. 
>	ACCEPTED. 
>	[R27] 
>	A common attribute should be declared as a global attribute only in 
>	cases where the attribute's meaning is identical no matter what element 
>	it is used on, and where the attribute is useful on every UBL element. 
>	This rule applies to both external (such as xml:lang) and UBL-specific 
>	global attributes. 
>
>	Note that this rule allows for the creation of common attributes that 
>	are allowed on every element but are not globally declared, and that 
>	need documentation of their meaning in each XML environment in which 
>	they are used 
>	ACCEPTED. 
>	[R43] 
>	The number scheme must be the major number is a non-negative integer and 
>	the minor number is a non-negative integer. 
>	ACCEPTED AS IS. 
>	[R46] 
>	Each version Must have a namespace. 
>	ACCEPTED.  Move up above namespace rules.  Leave that to the discretion 
>	of the editor. 
>	[R47] 
>	Each minor version must be given a separate namespace. 
>	ACCEPTED.  Same as above. 
>	[R48] 
>	A published namespace MUST never be changed. 
>	ACCEPTED. 
>	[R49] 
>	When the URN changes to reflect a change in the namespace, this change 
>	will be reflected in the version number, either major or minor. 
>	ACCEPTED. 
>	[R50] 
>	Minor versioning must be limited to declaring new optional constructs, 
>	extending existing constructs and refinements of an optional nature. 
>	ACCEPTED. 
>	[R51] 
>	Changes in minor versions must not break semantic compatibility with 
>	prior versions. 
>	ACCEPTED. 
>
>	Does NDR agree that this list accurately represents rules that have been 
>	completed/finalized?  I'd like to maintain a list such as this for LC so 
>	that as NDR finalizes more rules LC can review them asap and implement 
>	as appropriate.  I can then also add a column which says which ones have 
>	already been implemented in the schemas so that NDR knows which ones 
>	will most likely not generate any further comments/issues. 
>
>	Thanks, 
>	Anne 
>
>
>
>	You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php
>
>  
>