Feedback on MNDR sections 2,3 & 4

["Bergeron, Donald L. (LNG-DAY)" <Donald.Bergeron@lexisnexis.com>]

Good morning,

 

I would like to thank the drafting committee for their excellent work.  I know that we will get valuable input over the next few days on the list and move on to work and close issues on the list and that the face-to-face next week.

 

I will use line numbers as my beginning point for my comments.

 

Here are my comments for section 2.

 

·         110 -- Consider adding a short description of exchange document at this point.  It would help the novice reader that this is a replacement for an earlier poorly named term that can create confusion.

·         118 -- You may want to note, that there is no generally accepted XML method for validating that this subset schema is a true subset.  SGML at the construct of architectural forms that allowed for the proof of a true subset.

·         184 -- Can this section also contain business process requirements that are necessary in support of the standard or standards?  The enforcement of standards very often requires a minimum business process set of requirements.  Are they allowed or supported here?

·         241 -- Under the definition here, there should be a requirement that such a spreadsheet the exportable to either a standard XML representation or at a minimum a comma separated value format.

·         255 -- ibid. 241

·         290 -- Frankly, I would strike this section in favor of it being included in the definitions.  This would lead to one-stop shopping and remove dual maintenance.

 

Here are my comments for section 3.

 

·         71 -- Is there an editor role?  Is it separate from the facilitator?  If there is an editor role in needs to be documented here.

·         91 -- This section needs to have a little bit of discussion included within it.  This meeting is needed much more for accountability reasons and for purely technical reasons.  This is a key facet of human engineering and it should never be minimized nor overlooked.

·         103 -- Please note here that those packaging guidelines are more included by reference rather than by a direct description.

·         121 -- Normally I'm not in favor of redundancy, but here I will make an exception I believe it needs to be in section 2 and here.

·         130 -- I would suggest also represented should be also completely or fully represented.  I would also note that care must be taken that no heed and rules or inferences are in bodied in the proprietary format.

·         133 -- Proprietary was defined in section 2.

·         136 -- ibid. my comments in section 2 at 241.

·         146 -- ibid. the spirit of my comments in section 2 at 241.

 

Here are my comments on section 4.

 

·         76 -- I would place a note here that it is assumed that the reader is aware off in conversant in the definitions in section 2.

·         130 -- I think that this may be a good idea.  However, if you take this approach in need to be very explicit that these values are subject to change via a robust change control method.

·         General note: I think that the change management of this entire set needs to be more fully fleshed out and reinforced.  I have found, and since a package will spend most of its life in change control rather than development that the most dangerous period in any standards life cycle is maintenance.  Even in internal standards, I've often found that the semantic drift most often occurs subsequent to the development effort.

 

Regards,

Don

Donald L. Bergeron
Systems Designer
LexisNexis
donald.bergeron@lexisnexis.com
O 937-865-1276
H 937-748-2775