Comments on MNDR section 2

["Scott Came" <scott@justiceintegration.com>]

Tom and all, I have the following comments on wd-ijtc-mndr-sec2-v02.

line 115ff and 142ff:  Would like to
see included in the definitions the notion that subset and constraint schemas redefine the GJXDM namespace.

line 133:  What is a "local" extension?  Implies a geopolitical reason for creating an extension schema,
but that is too restrictive.  There are other extension contexts beyond geopolitical ones (e.g., domain-based,
temporal, etc.)

line 145:  Need to get more specific in defining constraint schemas, or more specifically,
the difference between subset and constraint schemas.  I believe the difference is that subsets simply remove
components (in the XML Schema spec sense of that word) from the namespace.  Constraint schemas either modify component
properties (like minOccurs and maxOccurs) or add certain element information items (like the choice compositor) the
further restrict the set of schema-valid instances.  (There has to be a more general definition...we need to pin this
down.)

line 170: (typo) "...a proprietary format is ubiquitous..."

line 175: reference
the Open Source Initiative web site for a formal definition of what constitutes an open source license (OSI owns the
trademark on the term "open source", so it's whatever they decide)

line 206ff:  The documentation
should include explicit declaration of context.  For now, this can be informal (e.g., "Reference GIEP for
Incident Report, national scope" or "Traffic Citation for Thurston County, Washington").  Later, once
we define context more formally a la UBL, we can structure this information.

line 218ff: All of these rules
are provided, in more detail, in subsequent sections.  We should consider whether the duplication is
necessary/desired, and edit accordingly.

line 221ff: convert these from bullets to numbered subsections

line 235: (typo) "business data"

line 236: I'm not sure the word "proprietary"
as used here fits with the definition above

line 259:  I feel strongly that the SSGT is a de facto standard
in the community.  It is the baseline that is freely available and ubiquitous.  Since what we're after is reusability
of artifacts without requiring use of proprietary tools that may have created those artifacts, I think we should
change this to a MUST.  (That is, a GIEPD MUST include a wantlist.)  Otherwise, someone attempting to reuse a GIEPD
may be forced into using a proprietary tool or process used to create the schemas.  (It's okay for them to do so if
they wish, but we don't want them to be forced to do so.)  For this to work, we need to reference the wantlist
specification, which I believe is available on the GTRI website.

line 301:  How can this be normative?  I
would suggest: "a GIEPD must include a subset schema and/or constraint schema, unless the GIEPD Process
Documentation explicitly states that the GIEP is dependent on the entire GJXDM namespace".  Or something like
that.

line 310:  Similar comment as per 301.  I would suggest: "a GIEPD must include an extension
schema if it contains schema components outside the GJXDM namespace".  (Contains may be a bad word.)