Comments on John's latest posting

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

John, thanks for consolidating comments.  Further comments are as follows:

1.  Sec 6.3.8 (p. 19 ff),
regarding user-defined attributes...  this is not something I feel strongly about.  I can see the point, how it may
hurt interop.  It's a SHOULD NOT anyway...so it's ok by me.

2.  Sec 6.3.9.1 (p. 23 top), regarding
extension vs. document schemas...  Putting something in an extension schema increases, rather than decreases, the
opportunity for reuse in other documents.  A document schema encapsulates the structure of a particular exchange
document.  For example, document schemas correspond to Document elements in the Information dimension in JIEM. 
However, several documents could certainly reuse lots of structures from a common extension schema (e.g., in LA
County, all PersonType objects have a boolean indicator, to tell whether they have a star on the sidewalk in
Hollywood...you'd certainly want to reuse this on the LA incident report, booking report, complaint, etc.)  The real
driving force here is, when you have multiple global elements defined in a schema, the parser is not able to enforce
any particular one of them as the root.  That's why we need document schemas.  I know the GTRI documentation says you
can do it either way, but I think to improve interop we should restrict down the choices.

3.  Sec 6.3.9.2
(p. 24 top)...I retract the comment.

4.  Sec 6.3.9.4. (p. 26)...  My issue was that rule ELD5 seems to be
dictating something about GJXDM, which I thought was out of scope.  I think the rule should be changed to read
"every user-defined simpleType".

5.  Sec 6.3.9.5 (p. 26)...  So, do we not need this anymore?

6. Sec 6.3.12.2 (p. 35)...  The problem with this proposed rule is, it is inconsistent with the proxy
architecture in GJXDM (GJXDM schemas have circular dependencies of the kind mentioned here.)  It would be awkward if
this were inconsistent with rules we put forward for the extension and document schemas.  In any case, most robust
tools can handle the circular dependencies just fine.

7.  Sec 6.3.13 (p. 37)...  I guess I'm being picky
here...is this rule intended to say "on each user-defined complex type, you have to specify the xsd:final
attribute, and set it to true or false as appropriate"?  Doesn't this rule simply restate a fact about XML
schema?  If so, is it of any value in improving interop?

Now I have a ditto comment on the new GXS9.

8.  Sec 6.3.18 (p. 39)...  Is this really true?  If I have a complex type that uses xsd:choice, can I really
not extend that type?  We need to find something in the schema spec to support this, or else explain really why
xsd:choice inherently prevents extension.

9.  Sec 6.5.3 (p. 42)...  So we are agreed to delete this section
then?

10.  Sec 6.8 (p. 52)...  If we include a "tools in use" section, I would like us to mark it
clearly as non-normative.  I would also like to include a paragraph that indicates what the criteria are for a tool
being "in use".  I think we should discuss this issue further on a conference call.

11.  Sec 7.1
(p. 53)...  I guess I don't see the point of the rule.  A proper document schema has only one global element defined
within it, so there is no possibility ever to be in violation of the rule.

12.  Sec 7.2 (p. 53, rule
IND7)...  I am ok with including this as information, and taking it out of "rule format."

Thanks.
--Scott

Scott Came
President and Principal Consultant
Justice Integration
Solutions, Inc.
Olympia, Washington
360-402-6525
scott@justiceintegration.com
http://www.justiceintegration.com