Feedback on MNDR sections 4, 6, 7

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

Good morning,

 

Again, I would like to thank the drafting committee for their excellent work.  Please note, I hope these comments are useful.  I have not attended any of the workshops where this methodology has been used.  Therefore my comments are purely based on my industry experience.  If the domain experience runs counter to my suggestions it should likely take precedence.  However, all from the synthesis brings out the best approach.

 

I will use your text hierarchy numbers as my beginning point for my comments.

 

Here are my comments for section 4, 6 & 7.

 

·         2 -- entire section -- This section is extremely important.  Downstream, it removes a tremendous amount of time wasting activities and frustration.

·         2.6 -- I suggest that whatever table style is used that it be checked for its ability to be transformed into Excel or XML CALS table format.

·         6.2 -- In the document set, this is now the third set of definitions for this set of objects.  I would pick the one in definitions and cross-reference in all other instances.

·         6.3.1 -- paragraph beginning the W3C -- Here's where one may want to consider tuning the definition to point at W3C schema being used for the document type validation, rather than as implied here for all uses.  Keep in mind being type valid will not and cannot support the enforcement of all the business rules within the domain.  The terminology that I use for these additional constraints in the adherence to these constraints is conformance.  Often, I will use the schema language relax NG (OASIS standard) and Schematron.  I use these as additional conformance tools.  Note: although Schematron has schema in its name is more a business rule constraint language.

·         6.3.2 -- I urge you to state that any schema created without documentation should be deterministically generated from a master.  The generation of this schema, must never be left to chance.

·         6.3.2 .2 -- I think it's important here to include the relationship between this and the use of XML processing instructions.  Are they precluded?  Should they be used in preference to this?  What  is the precedent relationship between this construct and XML processing instructions when both occur in a document instance.

·         6.3.9.6 -- This area may need further thought depending upon the results of Winnie's white paper.

·         6.3.9.7 -- yeah

·         6.3 .11 -- Consider, advocating for a three node versioning scheme.  The third node comes in very handy when you're changing documentation within the schema.  They can also come in handy when changing active schema structures in a way that does not affect behavior that affects readability and maintainability.  This last one, is a little bit trickier and in truth I tend to avoid It.  But these should the third node in the changing documentation has allowed us to avoid some thrashing in version management.

·         6.3.17 -- yeah

·         7.2 -- please see my comments ibid. 6.3.1.

·         7.4 -- you may want to cross-reference this to the concept #IMPLIED from DTDs.  And since, a document instance might be used outside the scope of a validating parser the TC should decide if the decisions should be made based on the pre-validation information set or the post validation information set.  This will be one of your most crucial decisions!  If you choose to post validation information set then you preclude the effective use of a number of XML related technologies such as relax NG and Schematron.

 

Please note, I did not cover the appendices, but I hope this provides you useful feedback.

 

 

 

Regards,

Don

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

---

From: Bergeron, Donald L. (LNG-DAY)
Sent: Tuesday, April 19, 2005 6:58 AM
To: 'scott@justiceintegration.com'; legalxml-intjustice@lists.oasis-open.org
Cc: Bergeron, Donald L. (LNG-DAY)
Subject: Feedback on MNDR sections 2,3 & 4
Importance: High

 

·         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