OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency] HAVE comments - explicitly identifying the normative parts in the data dictionary



Thanks, Tim.

As I said, I have no problems with whatever resolution the TC will adopt.

Let me just note that I think we need to comply with the OASIS rules on
conformance language (use of MUST etc.) in this first version of the
standard.  The "Usage" line, for example, does not use such language.

...unless OASIS says this can be deferred to the next version, in which case
I have no more comments to make!

Alessandro
 

> -----Original Message-----
> From: Timothy Grapes [mailto:tgrapes@evotecinc.com] 
> Sent: Friday, September 28, 2007 11:26
> To: mary.mcrae@oasis-open.org; 'Alessandro Triglia'; 'Lee Tincher'
> Cc: 'Dwarkanath, Sukumar'; emergency@lists.oasis-open.org
> Subject: RE: [emergency] HAVE comments - explicitly 
> identifying the normative parts in the data dictionary
> 
> All,
> 
>  
> 
> Up front I want to highlight the quality and thoughtfulness 
> of the comments provided by Alessandro.  The focus now is 
> upon the process, approach and timing to address this valid 
> input given the process this standard has already been though 
> and consideration of moving targets.  Mary's clarification is 
> an important one and we need to focus on the goal.  I believe 
> that the approach being proposed is backwards.  My opinion is 
> that both the  schema and data dictionary should be normative 
> and be consistent.  Rather than skirting the actual issues by 
> messing with definitions of  what's normative and not 
> normative in the dictionary, we should decide what changes 
> can be incorporated now with minimal effort, and with no risk 
> of an additional public review.  Substantive changes should 
> not be addressed now, but in a future release 1.1 in 
> conjunction with the NIEM data dictionary/RIM proposal Lee 
> referred to (see below).  In this context, I need to 
> understand which of the 70 comments specifically may be 
> addressed now vs. a later release.
> 
>  
> 
> So, my input for the immediate issue is this:
> 
>  
> 
> 1.	I am not in favor of incorporating changes at this time 
> that would take much more than a week of editing and review.  
> My opinion is that the geo issues could take us well beyond. 
> 2.	I am not in favor of incorporating changes that would 
> put the HAVE standard in any risk of yet another public 
> review beyond the 60-day it is now entering. 
> 3.	I believe the entire data dictionary should be 
> normative (this is supported by and consistent with Dublin 
> Core).  However, if compromise is needed perhaps "Comments" 
> and "Requirements Supported" could be non-normative, with the 
> rest (element, type, usage, definition) normative. 
> 4.	Now, moving forward I agree with Lee's input regarding 
> NIEM.  A concept / proposal was presented during the San 
> Diego face to face meetings.  Understanding more needs to be 
> worked out, the TC gave a head-nod in principle which opened 
> the door to pursue further program alignment work/agreements 
> between the DM program, NIEM and NIMS.  Those agreements are 
> being finalized and DM has just this week formally asked that 
> the OASIS EM-TC now engage in defining a plan and process.  
> 
> 	a.	I agree that Alessandro note does support 
> looking at NIEM as a common data dictionary / RIM concept, 
> consumed by EDXL with a closed loop process to maintain the 
> that dictionary (the NIEM EM domain).  
> 
>  
> 
> Just my 2-cents.
> 
>  
> 
> Thanks,
> 
>  
> 
> Tim
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]