XML NDRG Comments, December 12, 2005

DRAFT - Federal XML NDR Comments Matrix
Starting Line #	Relevant Page, Section, or Rule #	Proposed Change	Priority (High, Normal)	Date Submitted	Submitter Name	Accepted change (Y/N)
-	XMLNDR  EPA XML Design Rules and Conventions from 2003	I was under the impression that some EPA XML guidance would be added to this site. Since that has yet to happen, I’ve added the 2 EPA documents I had from 2003. If there are more recent versions of EPA guidance, I’d appreciate if they would be added to the Government Standards folder. I’ve also heard of Air Force standards. Does anyone have access to them?	Normal	2-Jul-2005	Sall	LMI: We don't believe that this comment requires any change to the NDRG document.
-		(See IC Position Paper section 4.1 Define the Adoption Process)		19-Jul-2005	ICMWG	LMI: This comment is being addressed outside of the scope of the document.
-		(See IC Position Paper section 5.1 Propose Guidelines Rather Than Enforce Rules)		19-Jul-2005	ICMWG	LMI: The current document draft reflects the decision of the WG that, largely, it represents guidance but that there are some rules that MUST be impemented for inter-agency data exchange.
All	All	General guidance vs. rules based (change all applicable 'MUST' rules to 'SHOULD')	High	15-Jun-2005	Ambur	LMI: The document has been updated to reflect this comment. (see section 1.4) The document provides
All	Overall	Audit entire XDG to ensure that all XSD element and attribute references appear in lowercase since XML is case sensitive. Examples of the problem are sub-section headings 5.1.3.2 to 5.1.3.4.	Normal	2-Jul-2005	Sall	LMI: Agreed. The document has been updated to reflect this comment. Greg will confirm that this is completed throughout the doc.
All	Overall	The XDG uses variations of these terms: XML Schema, Schema (u/c), schema (l/c), XML schema (l/c), and DTD. The variations are not used consistently, nor are they well-defined. Recommend that the terms be defined on page 1 or perhaps at the beginning of Section 1.3 (rather than at the end) since this distinction is at least as important as your notation conventions. schema – model, which doesn’t imply XML at all XML schema – any modeling language written in XML syntax (W3C XML Schema, DTDs, RELAX-NG, etc.); recommend only using this form when you mean generically any XML-based schema language XML Schema – a particular language developed by the W3C used to describe a class of instances that conform to a particular model; also used to mean a given schema written using the W3C XML Schema language. Schema – recommend never using u/c without “XML” in front. Should also mention that the abbreviation “WXS” (for “W3C XML Schema”) is also used (besides “XSD”).	Normal	2-Jul-2005	Sall	LMI: Agreed. The document has been updated to reflect this comment. (section 1.4)
All	XMLNDR Global - inconsistent font conventions	While this may seem minor in the scope of things, it is so frequent a problem in the XDG that I find it very distracting. Inconsistency of fonts is something to make readers conclude that the editors haven’t paid sufficient attention to detail, much like typos. The use of Courier (fixed width) font should be reserved strictly for code, primarily element and type names and XML excerpts. Please do not use it for emphasis or other terminology.  Your conventions state that you are using italics for special terms defined in Appendix A, when not used for title or emphasis. That sounds good; please perform a consistency check. See section 1.3 for your conventions and section 5.1.* for obvious inconsistencies. There are others problems in other sections as well.	Normal	2-Jul-2005	Sall	LMI: Agreed. The document will be updated before final draft review to reflect this comment.
116	p.1-2	On page 1-6, footnote 1 points to http://www.xml.gov/working_group.htm. (which no longer exists). It should point to: http://xml.gov/discussion.asp	Normal	2-Jul-2005	Sall	LMI: This footnote is not in the latest draft document.
161	p.1-8, STR1	This rule uses "must" - is this too strong? That is, since this is not formal policy, can this document state that agencies *must* adhere to a prescribed hierarchy of standards? I believe such policy (the hierarchy) must be issued by OMB.	Normal	16-Jun-2005	Chiusano	LMI: The document has been updated to reflect this comment given that it contains rules and guidelines. Also, different standards will likely propose competing approaches to myriad design issues. If the term MUST is to be used, extensive analysis may be required to identify how, specificaly, these standards are to be used.
161	STR1	(See IC Position Paper section 5.12 Voluntary Consensus Standards)		19-Jul-2005	ICMWG	LMI: The document has been updated to reflect this comment- with the exception of the change to 'De facto'. Sites such as 'http://en.wikipedia.org/wiki/De_facto' and 'http://www.isoc.org/internet/standards/papers/amr-on-standards.shtml' seem to indicate that there is relevant precedant in the field of law that suggests that the term 'De jure' is appropriate.
165	p.1-9, STR1	Recommend additional explanation for the hierarchy at top of p.1-9. For example, what is a "de jure" VCS? What are "cross-sector" and "sector-specific" VCSs? Examples of each level would also help	Normal	16-Jun-2005	Chiusano	LMI: The document has been updated to reflect this comment. We believe the list of VCS examples should be sufficient.
165	STR1	I suspect the wording for STR1 should be: De facto VCS Horizontal VCS Vertical VCS Government-wide standards Agency –specific standards I agree that examples are needed.	Normal	1-Jul-2005	Sall	LMI: The document has been updated to reflect this comment- with the exception of the change to 'De facto'. Sites such as 'http://en.wikipedia.org/wiki/De_facto' and 'http://www.isoc.org/internet/standards/papers/amr-on-standards.shtml' seem to indicate that there is relevant precedant in the field of law that suggests that the term 'De jure' is appropriate.
171	p.1-9, STR2 and STR3	Recommend striking these rules, as they are out of scope of naming & design rules. They address policy and operational aspects	Normal	16-Jun-2005	Chiusano	LMI: We believe that it is appropriate to leave these 'rules' in the document since they pormote awareness within the XML development community regarding how XML Schema content should be discovered and submitted for candidate reuse.
182	p.1-9, section 1.4.1	Recommend striking this entire section, because (a) I don't believe that we should be favoring one standards consortium over another, (b) if there are competing standards within/across consortiums, agencies should have the freedom to select whichever are best for their needs, and (c) STR1's reference to PL 104-113 and OBM A119 should suffice for this aspect.	Normal	16-Jun-2005	Chiusano	LMI: We'd like to discuss this with the commenter.
197	p.1-9, STA1	I believe that this rule really means to say "all schemas must be based on W3C Schema" (as opposed to RELAX NG, for example). To say that "all schema design rules must..." does not make sense, unless we intend that agencies will be writing their own schema design rules (in which case they would not need this document).	Normal	16-Jun-2005	Chiusano	LMI: The reference to design rules has been removed. Joe writes: ''in which case they would not need this document'. Is this true ? Isn't this document meant to serve as a guideline with which agencies may choose to create their own NDRs ?
203	p.1-10, STA2	Not sure what we mean by "and messages". Do we mean to say that any messages exchanged between agencies must be based on...(see rule for rest)? Also, to say "all schema must be based on..." is redundant, as that was stated in STA1.	Normal	16-Jun-2005	Chiusano	LMI: The document has been updated to remove the 'and messages' reference. It's purpose is unclear and extraneous.
203	[STA2]	All schema and messages SHOULD be based on the W3C suite of technical specifications holding recommendation status. Applications SHOULD NOT implement W3C technical reports at other stages of the development process, or other draft products of Voluntary Consensus Standards bodies.  In particular, applications SHOULD NOT implement or rely on W3C notes or other draft documents from other organizations.	Normal	23-Jun-2005	Vincent	LMI: Please clarify this comment.
203	[STA2]	[I would strike the rest of this section.]	Normal	23-Jun-2005	Vincent	LMI: We believe this content does not distract from the purpose and scope of the document.
203	STA2	“All schema and messages” being based on W3C suite seems to prohibit the use of many other VCS standards (e.g., those from OASIS). For example, if taken literally, it would disallow using UBL or CCTS (even though *they* are based on W3C specs). “recommendation status” is certainly highly desirable, but the text in Sec. 1.4.1 is far too restrictive to be adopted government-wide. If an agency has a need to use XQuery, for example, which has been one or more Working Drafts for over 5 years, they will use it. IMO, the real point to be made is that if there are 2 competing specs and one is more mature than the other and/or by a more widely accepted source, than that should influence the choice. But even then, some critical feature of the less mature spec could override the maturity argument.	Normal	2-Jul-2005	Sall	LMI: We believe that any XML specification development MUST be done in accordance with the W3C rules of that language. We assume that a literal interpretation will not be understood here. Also, CCTS is not based on any XML standard. Any specifications that extends the W3C XML Schema Recommendation may be used but they MUST adhere to W3C XML Schema. The term 'based on' has been replaced with 'conformant to'. Also, we believe that this document MUST not promote use of specifications that are not yet recommended by their respective datdnards organization. If agencies choose to adopt these technologies, they may certainly do so at their own risk, but we believe this document should discourage that practice. To what line does section 1.4.1 refer ?
203	STA2	(See IC Position Paper section 5.13 Permit Specifications that are Not Quite Recommendations)		19-Jul-2005	ICMWG
208	p.1-10, STA2	text under rule: Recommend striking all of this text (under "Production Applications"), for reasons stated earlier (should not favor a single standards consortium, already covered the general concepts in STR1, etc.).	Normal	16-Jun-2005	Chiusano	LMI: We believe this content does not distract from the purpose and scope of the document.
231		All software and software components (XML parsers, generators, validators, enabled applications, servers, databases, operating systems), and other software acquired or used by Agencies SHALL be fully compliant with all W3C XML technical specifications holding final recommendation status and with final specifications produced by accredited standards bodies.  (This should be deleted.  In fact, no two parsers operate the same way.  There is no accreditation or certification system to test whether a parser, etc. is “fully compliant.”)   This rule is not realistic and even if it were, could not be verified.	Normal	23-Jun-2005	Vincent	LMI: Agreed. The document has been updated to reflect this comment.
240	p.1-11, STA3	Recommend changing this to state that users should defer to the conformance clause of each specification/standard, and making it general (not W3C-specific). As written, the rule may prevent business needs of agencies from being carried out, as these needs may be sometimes be satisfied with proprietary (agency-specific) extensions.	Normal	16-Jun-2005	Chiusano	LMI: We think this rule should stand but shold be clarified to state that no attempt be made to modify the XML Schema language per se. We agree that a reference to conformance/compliance/certification clause should be included and the document has been updated accordingly..
240	[STA3]	Proprietary extensions to the W3C specifications MAY be used, but SHOULD BE USED with caution..	Normal	23-Jun-2005	Vincent	LMI: If this refers to attempted modifications to the core XML Schema specification, we disagree.
247	p.1-11, section 1.5.1	Recommend striking this section, as most/all of the principles are so general that they cannot be easily adhered to, and instead representing them as part of rules. Some are also not clear. Examples: - Item #1 (Internet Use): What does "straightforwardly usable" mean? Very broad term that is so subjective that it would be difficult to find a case in which an implementation was not "straightforwardly usable".- Item #3 (Legibility): "human-readable and reasonably clear" - very subjective.- Item #4 (Simplicity): "as simple as possible" - very subjective.- Item #5 (Component Reuse): "common features" - what does this mean?- Item #6 (Standardization): "kept as close to one as possible" - in what scope? Within an agency? Across the federal government?- Item #7 (Customization and Maintenance): "must facilitate customization and maintenance" - how does a schema accomplish this?- Item #8 (Prescriptiveness): What does "prescriptiveness" mean here? What are "precise, tight" content models ? - Item #9 (XML Technology): Already covered earlier in document, in discussions on standards.- Item #10 (Legacy formats): Define "legacy".	Normal	16-Jun-2005	Chiusano	LMI: Some of these changes have been made.
247	1.5.1	Regarding Section 1.5.1, I agree with Joe. The wording in this section is far too vague to be really useful. For example, SVG is a W3C REC, but how “human readable” is it? There is plenty of geospatial data wrapped in XML that may not be very “legible”. So what? If the processing software can interpret XML and do something with it (render it, filter it, stuff it in a database), that’s far more important. “Simplicity” – This statement is extremely subjective and not measurable. “Standardization” – Expressing the same information in one way government-wide is a lofty goal, but leave this to NIEM, not to this XDG. How can a developer” make operation sense out of this? “Legacy formats” – This wording is bound to inflame anyone on the fence about moving to XML in the first place. Nearly every agency in the government *does* have to worry about legacy formats. To dismiss This whole section should be removed; at a minimum, it requires a significant re-write with more detail. I believe it is based on similar wording from a draft CCTS Users Guide.	Normal	2-Jul-2005	Sall	LMI: Some of these changes have been made.
276	p.1-12, section 1.5.2	Recommend turning this section into rules. It is quite verbose, and doesn't even really arrive at the central point until the third paragraph.	Normal	16-Jun-2005	Chiusano	LMI: Please provide the line number for the last document draft.
276	p.1-12, section 1.5.2	Prescriptiveness – Federal schema design will balance prescriptiveness in any single usage scenario with prescriptiveness across the breadth of usage scenarios supported. Having precise, tight content models and Datatypes for schemas that represent data formats is a good thing.  (I do not think this document does or should describe rules for XML document formats.  This having been said, document formats need loose, flexible schemas with mixed content.  So, it is important to associate tight content models and data types with data formats.  Otherwise, there will be misunderstanding.)	Normal	23-Jun-2005	Vincent	LMI: We need to better understand the suggested change of this comment.
297	p.1-13, top	If this section is kept, recommend removing the reference to CCTS (for context). I believe that this document should not be tightly bound to any single data modeling methodology, including CCTS.	Normal	16-Jun-2005	Chiusano	LMI: What is the line number of this reference in the latest document draft ?
302	b	Recommend defining "data-centric" and "document-centric". For an example, see the EPA XML Design Rules document.	Normal	16-Jun-2005	Chiusano	LMI:  This work is underway.
302	1.5.3	I agree with Joe that in Section 1.5.3, you need to define “document-centric” and “data-centric” (probably with an example). Also agree that your assertion about XSD vs. DTD use cannot be validated. It would be far more useful in this section to point out specific advantages of XSD over DTD to motivate developers to pick the former over the latter, such as: -          strong data typing with 44- built-in types -          flexible constraint mechanism via “facets” including regular expressions -          derivation by restriction and extension -          uses XML syntax -          precise control over multiplicity via minOccurs and maxOccurs (.e.g., can specify element repeats from 7 to 12 times) -          namespaces -          etc.	Normal	2-Jul-2005	Sall	LMI: Please provide the document line-number from the latest draft.
306	p.1-13, section 1.5.3	Recommend striking the assertion that data-centric approaches now outnumber document-centric approaches, for the following reasons: (a) it's not relevant, as XML will be used for both approaches regardness of which is more "popular", and (b) there is nothing provided to support the assertion.	Normal	16-Jun-2005	Chiusano	LMI: Agreed. The document has been updated to reflect this comment.
311	p.1-13, section 1.5.4	Recommend striking this, or making it a rule. The last sentence was also covered earlier in the discussions around standards.	Normal	16-Jun-2005	Chiusano	LMI: Please clarify the line number or section in the latest draft of the document.
311	p.1-13	This section is confusing to me.  We distinguish between “Code generation” and “schema generation.”  Schema generation is generating XSDs from some information source.  Code generation is generating code (e.g., VB or VB.NET) from XSDs (also called “data binding” if you do an Internet search.) The title says “code generation” but the first sentence describes “schema generation.” In principle, I agree that these rules should not favor one product over another product for either code generation or schema generation.  However, these rules should be designed to facilitate (vendor-neutral) schema generation and code generation.  XML schemas are useful because they are XML – which means that you can very easily use the XML for schema generation and code generation. The corresponding disadvantage is a performance hit.   If the rules do not leverage the XML characteristics of XML Schemas, then you may as well use DTDs.	Normal	23-Jun-2005	Vincent	LMI: Please provide the document line-number from the latest draft.
321	CHAPTER 2 COMMENTS	Recommend striking entire chapter, as it belongs in a data modeling manual not an NDR document.	Normal	16-Jun-2005	Chiusano	LMI: It seems important to provide the federal XML audience with the context from which XML Schemas are to be developed. It seems appropriate to cite such modeling systems as UML since that is a prevalent, gobal method for modeling information. Readers need to understand how their syntax-neutral information models will be translated into XML Schema data models.
321	Chapter 2	I would move this to an appendix.  I do not necessarily think you should strike it	Normal	23-Jun-2005	Vincent	LMI: We believe this section has direct applicability to the context from which XML developers are going to approach this document.
321	Section 2	Section 2 does not provide enough information for someone who doesn’t know much about UML modeling and is far too obvious to anyone who already is familiar with it. Therefore, either go into much more detail with a complete example (including XSD) or refer readers to a number of good books and other resources about modeling, such as the OMG site and UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition by Martin Fowler	Normal	2-Jul-2005	Sall	LMI: Agreed. This document should more clearly state how UML models can be translated into XML Schema models.
326	Section 2-1	I recognize that this section does not prohibit a one-object-one-schema approach.  However, does not make it clear that there are alternatives.  I think this section should make clear that there are three alternatives:                         - One schema, one namespace – all objects - Modular schemas, but many objects to one schema.  (one or several namespaces per object) - Modular schemas, but one object to one schema. (one namespace per object/schema)	Normal	23-Jun-2005	Vincent	LMI: This is possible, but we consider it a low priority.
346	Section 2-2	It would be good to have XSD examples to show a “complex data element” and “simple data element”.  Although I have a general idea of what you mean, I can think of several XSD constructs that might be considerd “complex data elements” and “simple data elements.”  Examples would help clarify this.	Normal	23-Jun-2005	Vincent
379	General:	Most rules in this chapter are missing explanations/justifications (I know that's obvious, just emphasizing it).	Normal	16-Jun-2005	Chiusano	LMI: OK
382	XMLNDR Section 3.1, GXS1, ELD1	In Section 3.1, the second sentence is an example of the “schema” vs. “Schema” confusion mentioned in an earlier email. In GSX1, the Copyright Notice appears twice (beginning and end). The terms “CommonComplexElements: and “CommonSimpleElements” are never explained in this section. While I can imagine what this means from the UBL NDR base for which this document is derived, further clarification is needed. This section clearly needs an example, preferably one that can be used to support the other rules that follow. In 3.1.1, the repeated word “will” seems out of place. Suggest replacing “will” with SHOULD or MUST, as appropriate. In ELD1, the term “Schema expression” is used but never defined. I cannot find this terminology in W3C XSD Part 1 or 2, which is your only stated source.	Normal	2-Jul-2005	Sall	LMI: The 2nd copyright notice has ben removed. LMI: This work is underway. LMI: We will remove references to 'Schema expression'
384	p.3-1, GXS1	This diagram is not very clear, and it can be better organized. Some suggestions: Use bulleted lists - Provide an example of each item (Target namespace, etc.). Perhaps it is best to have a single example that represents the entire box (i.e. with a targetNamespace declaration, etc.) with the various items labeled.	Normal	16-Jun-2005	Chiusano	LMI: Please clarify during comment review.
384	[GXS1]	It is not useful to put any of this information in unparsable comments <!--  and à.  This information should be in XML xsd:annotations in XML elements in a different namespace (e.g, the drm namespace).The first child of the <xsd:schema element should be xsd:import/xsd:include.  I prefer the following order:                                                           xsd:import/xsd:include xsd:complexType xsd:simpleType xsd:element xsd:group xsd:attribute	Normal	23-Jun-2005	Vincent
384	XMLNDR GXS1	Sorry. Forgot to mention that GXS1 use of “MUST” and “as applicable” is confusing.  For example, why do government-developed schema has a “Copyright Notice”?  (stated as “applicable” at beginning and “required” at the end. If the intention is notices about using specs developed by others, make this clear. Who decides what is “applicable” in GXS1? The agency? The developer?	Normal	2-Jul-2005	Sall	LMI: Agreed. Unless there is any clear reason to include a copyright notice, it should be removed. The term MUST has been changed to SHOULD.
426	p.3-2	I would not strike the existing rule, but I would add an additional rule that makes it useful to applications.  This is also something that NIST (or others) can test programtically.	Normal	23-Jun-2005	Vincent	LMI: What rule ?
431	p.3-2, section 3.1.1	Recommend removing the discussion of application space handling, as it clouds the issue. The bottom line is that we want to be able to unambiguously identify in a schema what we intend to be the root element for XML instances that conform to that schema. Period.	Normal	16-Jun-2005	Chiusano	LMI: Agreed. The relevance of application space handling to the topic at hand is a bit unclear. The doicument has been updated to reflect this comment.
448	XMLNDR Section 3.2	NMC1 - I believe Joe raised this, but “dictionary entry name” and “fully qualified path” need to be explained by definition and example. MDC1 – What is a “library” in this context? Where exactly are the “approved datatypes”? Since this isn’t UBL or CCTS that we are really talking about, this rule makes little sense to me. You certainly don’t mean the 44 built-in datatypes in XSD. MDC2 – Suggest you define “mixed content”. Even though this is standard XML/SGML nomenclature, not all techies know it. GENERAL – IMO, wherever a “MUST” is stated in a rule, a strong justification needs to be given. Essentially, you are limiting the flexibility of the XSD language and as a developer, I will always want to know why.	Normal	2-Jul-2005	Sall	LMI: NMC1 - The document has been modified to reflect this comment. MDC1 - The document has been modified to reflect this comment. MDC2 - The document has been modified to reflect this comment. GENERAL - Agreed.
450	p.3-3, NMC1	As a reader, I am saying to myself "What is a dictionary entry name?" and "What is a FQP"? Recommend moving this rule to after these concepts are discussed (assuming they are discussed later), or discuss them here.	Normal	16-Jun-2005	Chiusano	LMI: see previous comment
450	[NMC1]	It is unclear what you mean by “disctionary entry”.  It is unclear what you mean by “fully qualified path”.	Normal	23-Jun-2005	Vincent	LMI: see previous comment
454	p.3-3, NMC2	Recommend striking this rule. It is policy/governance, which is out of scope of NDR. Also not sure what is meant by "libraries" here (a moot point if rule is struck).	Normal	16-Jun-2005	Chiusano	LMI: This rule has been removed.
454	[MDC1]	It is unclear what you mean by “approved data types.”  Are these W3C XML Schema xsd data types or some other data types.  Does this prohibit the use of simpleTypes?  Who is the approval authority?	Normal	23-Jun-2005	Vincent	LMI: The document has been modified to better explain what is meant by approved data types.
456	[MDC2]	Mixed content SHOULD NOT (should avoid) be used in data centric schema except where contained in an xsd:documentation element	Normal	23-Jun-2005	Vincent	LMI: Please clarify this comment.
456	MDC2	(See IC Position Paper section 5.2 Allow for Possibility of Mixed Content)		19-Jul-2005	ICMWG
460	[ELD2]	I would strike the reference to document-centric schemas for the following reason (a) I do not think this document is about document-centric schemas and (b) in our work, we have never seen a need for an exception to the global element rule.  All elements and complex types should be declared globally – period.  There should not be any exceptions.  If there are exceptions, this greatly complicates processing based on the rules	Normal	23-Jun-2005	Vincent	LMI: The document has been modified to renove all references to documen-centric (with the exception of those stating that document-centric rule/guidelines are out of scope)
466	p.3-3, NMS1	As a reader, I am saying to myself "What is an internal schema module?".	Normal	16-Jun-2005	Chiusano	LMI: Agreed. The initial reference to this term requires sufficient description.
466	[NMS1]	This having been said, it is not clear to me what you mean by “internal schema modules”.	Normal	23-Jun-2005	Vincent	LMI: The document should now provide a sufficiently clear description of the term internal.
466	XMLNDR Section 3.4 - Namespaces (URN vs. URL)	I agree with all Joe’s questions and suggestions regarding the NMS1-4 rules. The removal of UBL-centric terminology is essential in this document, or else you must clearly define each term you’ve leveraged. If you drop into the first person, use “Editor’s Note” or some such notation or possibly your initials. I remain unconvinced that URNs should be required over URLs for several reasons: If existing applications use URLs, then to change to URNs breaks rule NMS7 about URI persistence. Many agencies would rather have easily resolvable URIs than permanent ones. Where is it described exactly how an agency can get its URNs formally assigned and registered? If it’s the paper you mention, give complete reference with a URL (or URN ;-). In my experience, far more schemas use URLs than URNs. This means insisting on URNs will impact numerous applications. Is it worth the cost?   URI SUGGESTION: Offer 2 parallel naming conventions (e.g., your 8 level descriptions), one illustrated with URNs and the other with URLs. Indicate the pros and cons of both. Then “recommend” the use of one over the other (if you must), but please strike SHOULD or MUST with regard to this choice. It is simply not going to be followed government-wide since it’s nearly a religious issue	Normal	2-Jul-2005	Sall	LMI: In regards to "Where is it described exactly how an agency can get its URNs formally assigned and registered?"… this is out of the scope of this document and should be added to the scope of the document associated with this NDRG that deals with governance and registry concerns. Additional text has been added to the document that outlines, objectively the criteria against which URL's and URN's should be compared. Recommendations are made accordingly.
469	p.3-4, NMS2	As a reader, I am saying to myself "What is a schema set version?".	Normal	16-Jun-2005	Chiusano	LMI: This rule has been reworded slightly and explanatory text has been added.
469	[NMS2]	Again, this rule, which you say “schema set” appears to favor the second model.	Normal	23-Jun-2005	Vincent	LMI: Please clarify this comment. It is unclear what is meant by "the second model"
472	p.3-4, NMS3	As a reader, I am saying to myself "What is a Federal Namespace?". Also, what constitutes a "federally developed" schema module? If it was developed by a federal employee?	Normal	16-Jun-2005	Chiusano	LMI: The document has been updated
472	[NMS3]	It is unclear why there is this restriction.  I would agree that schema modules should only contain schema modules based on the same NDR.  However, if a private vendor were to develop schemas based on an NDR, then I see no reason why the federal government could not use those schemas.	Normal	23-Jun-2005	Vincent
475	p.3-4, NMS4	As a reader, I am saying to myself "What is a published namespace?" IOW, what makes a namespace "published" or "non-published"? However, in general, I would recommend striking this rule because (a) it is extremely restrictive (use of "never"), (b) what if an agency is absorbed into another agency and their namespace identifier needs to change? (c) most importantly, it should be part of a data management strategy.	Normal	16-Jun-2005	Chiusano
475	XMLNDR NMS7	Appears twice	Normal	2-Jul-2005	Sall	LMI: The duplicate rule has been removed.
477	pg. 3-4	I do not think there is consensus on this rule.  I would recommend a rule that allows URIs provided that: A URI used as a namespace SHOULD point to a file or directory that contains the schema. If the URI points to a directory, the directory should contain documentation and the schema.The namespace or some other information available to an application should allow the application to discover the location of the schema and its documentation in the directory. The URI location(s) should not be changed for the same version of the schema.Imported schemas should be located in directories relative to the primary schema that match xsd:import and xsd:include statements in the primary schemas.   Relative paths should be used, as opposed to hard coded paths, in xsd:include and xsd:import statements	Normal	23-Jun-2005	Vincent	LMI: The document has been updated to outline discreet criteria against which the URN and URL namespace options can be measured. Reference is made to the documentation issue you cite (in addition to RDDL).
478	p.3-4, section 2.4.2	All of a sudden, we have an "I" here ("I recommend" - with "recommend" mispelled). Who is this "I"? Should be more general ("It is recommended that..."). Also, we jump into the notion of URNs (the solution) here without even stating the problem!	Normal	16-Jun-2005	Chiusano	LMI: This does not appear to be in the latest draft of the document. Please confirm.
505	p.3-5, section 2.4.3	This is a duplicate of the rule I referred to in #9 above	Normal	16-Jun-2005	Chiusano
508	p.3-5, section 3.5	Recommend striking this section. Versioning should be addressed in a data management strategy.	Normal	16-Jun-2005	Chiusano
508	XMLNDR Section 3.5 - Versioning	While a versioning scheme made sense for UBL because it is an effort developed by a focused technical committee, it is hard to believe we can impose a versioning scheme that will be acceptable government-wide. Some program requirements (from RFPs, etc.) mandate their own versioning scheme. To follow one we suggest could mean not complying with program requirements. Recommend recasting this section in terms of “recommendations” or “suggestions” and striking use of MUST or SHOULD	Normal	2-Jul-2005	Sall	LMI: We recommend that the government move toward a common approach regarding versioning of XML Schema vocabularies. The versioning strategy will have a direct impact on the manner in which a common federal vocabulary is used, and therefore will impact its usefullness. The group may want to consider a no-namespace strategy for common federal Schemas so that they can be used easily within agency-specific situations.
508	VER*, VER8	(See IC Position Paper section 5.3 Versioning Scheme is Not Well Defined)		19-Jul-2005	ICMWG
510	pg. 3-5	As I have stated in email posts, I would avoid using the document-id for version control and would rely, instead, on the namespace.	Normal	23-Jun-2005	Vincent	[8/11] Apply URN/URL decision from namespaces and make the rule "SHOULD"
514	[VER3]	I would not allow a minor version change (any version change) without a change in the namespace.	Normal	23-Jun-2005	Vincent	LMI: We disagree and believe that inclusion of minor versions in the targetNamespace is problematic since backwards compatibility will be broken with each minor version rev.
550	XMLNDR Section 3.6 Modularity	This whole section needs a significant re-write (expansion) with appropriate motivation and scoping, definitions of all terms used, clear explanation of the diagram. Once again, terminology from CCTS and UBL is incorporated without explanation. Since the intention of the diagram seems to be to show what is dependent on what and what the multiplicities are, be clear about these relationships. Example: “The diagram shows that a Fed Complex Data El Schema Mod consists of exactly one Fed Simple Data El Schema Mod, one Fed Qualified DataTypes Schema Mod, and one Fed Unqualified DataTypes Schema Module. The Fed Unqualified DataTypes Schema Module, in turn, is based Source Standards….” Please include XSD examples of each of the types of “modules” referenced in the diagram and show how they are imported or included.	Normal	2-Jul-2005	Sall	[8/11] Expand section description of diagram. Ensure all terms and concepts are fully explained. Inquire about providing Spectrum as an example.
550	3.6, SSM16 to SSM22	(See IC Position Paper section 5.10 Modularity Section Needs Concrete Examples)		19-Jul-2005	ICMWG	[8/11] Build on other comment for line 550 by Ken Sall, by breaking up figure into three diagrams.
564	p.3-8, Figure 3-1	Recommend simplifying this diagram, else no one will read/comprehend it.	Normal	16-Jun-2005	Chiusano	[8/11] Breakup figure into three diagrams.
564	Figure 3-1	I do not understand this diagram	Normal	23-Jun-2005	Vincent	[8/11] Breakup figure into three diagrams.
567	p.3-8, section 3.6.1	This paragraph is very vague - I kept wondering why I was reading it (i.e. what is the significance). We may also consider striking it, since the discussion of VCSs was already covered in the Introduction.	Normal	16-Jun-2005	Chiusano	[8/11] Re-write section.  Follow from ATG descriptions of the various types.  Simplify model.
578	p.3-9, SSM1	What is a "root schema expression"? Schemas don't have expressions (XSLT stylesheets do).	Normal	16-Jun-2005	Chiusano	Remove word "expressions".
578	[SSM1]	Again, this indicates the second model, not the first or the third.	Normal	23-Jun-2005	Vincent	No change
578	XMLNDR Section 3.6.2 - Schema Modules SSM1-to SSM15	The lack of explanation of terminology makes rules SSM1-15 hard to evaluate. SSM8 – Who is constructing the “Federal Common Complex Data Elements” and where does it reside? If I am a developer in the Dept. of Redundancy Department, why is this a rule for me? Won’t I simply be leveraging this “module”? If so, how do I reference it? SSM9 – This rule introduces what appears to be a namespace prefix “fed:” with no explanation or mapping to a URI. And back in the namespace rules section, the only URIs were of the (rough) form “urn:us”, so this is confusing. SSM9-15 – Please be consistent in all naming conventions. Some of these contain spaces and some do not. What are you really trying to accomplish by these naming conventions anyway?	Normal	2-Jul-2005	Sall	[8/11] Address as done for comment 76.  SSM8 define that a registry will exist.  SSM9 place a pointer in the document that explains what the prefixes are. Revisit the names of each of the Federal schema modual and see if we can leverage the NIEM Universal core terms.
580	p.3-9, SSM2	What is a "root schema"? And how can a root schema be "dependent upon" type definitions or element declarations defined in another namespace? It can *include* or *import* these (perhaps that is what was meant).	Normal	16-Jun-2005	Chiusano	[8/11] SSM2 replaces "is dependent upon" with "uses".  Clarify the "that" from the part of SSM2, "...root schema modules from that namespace."  Explain relationship between root schema and imported schemas.
584	p.3-9, SSM3	Continuing along the same lines, did not understand this rule because the base concepts (e.g. internal schema module) have not been explained (apologies if I missed them).	Normal	16-Jun-2005	Chiusano	LMI: We believe this rule should be removed unless the group can provide justifcation for the inclusion (or import) of one root Schema into another root Schema. That is, assuming root Schemas follow a Request/Response model, then when would it make sense to include one RQ or RS into another RQ or RS ?
588	p.3-9, SSM4	Since I believe we are saying (or intend) that all agency schemas will be conformant with these rules, this rule seems moot.	Normal	16-Jun-2005	Chiusano	LMI: We agree that this rul seems extraneous, but to what extent is it true that all agency Schemas will be conformant with this NDRG. Other comments submitted herein state otherwise (regarding versioning, etc). We have removed this rule.
588	SSM4	(See IC Position Paper section 5.4 Permit Non-Conformant Imports)		19-Jul-2005	ICMWG
591	p.3-9, SSM5	Continuing along the same lines, did not understand this rule.	Normal	16-Jun-2005	Chiusano	LMI: This rule simply states that, from the perspective fo a root XML Schema, all other XML Schemas fall into 1 of 2 categories: internal OR external.
591	[SSM5]	An example would be helpful.  It is unclear what you meant by “external schema modules” and “internal schema modules”.	Normal	23-Jun-2005	Vincent	LMI: Figure 3-1 provides a visual depiction of how internal and external XML Schemas are to be referenced from the root Schema. In support of your comment, we have added a textual reference to that figure. Also, explanatory text has been added.
595	p.3-9, SSM6	Continuing along the same lines, did not understand this rule.	Normal	16-Jun-2005	Chiusano	LMI: This rule is meant simply to state that each internal XML Schema should be defined in the same namespace as the root Schema that needs to use its content.
598	p.3-9, SSM7	Continuing along the same lines, did not understand this rule (etc. for rest of SSMx rules).	Normal	16-Jun-2005	Chiusano	LMI: We'd like to discuss this with the commenter.
598	[SSM7]	An example would be helpful.	Normal	23-Jun-2005	Vincent	LMI: Agreed. We have added an example to clarify.
603	p.3-10, SSM8	What constitutes federal "common" complex data elements? Common within what scope? Across the entire federal government? Within a single agency? etc.	Normal	16-Jun-2005	Chiusano	LMI:  An explanation has been added to the document. These elements pertain to a the federal government as a whole.
606	p.3-10, SSM9	Is there really a need for us to require what schemas are named? Also, it seems odd to have a name of a schema that begins with a namespace prefix ID (fed:).	Normal	16-Jun-2005	Chiusano	LMI: We believe that a consistent naming convention will promote simplicity for XML Schema development as a whole. Regarding the namespace prefic, we are open to suggestions. Assuming a consistent naming convention, it will be necessary to denote somehow the domain to which an XML Schema applies.