RE: [ubl-ndrsc] First cut on Design Document

["CRAWFORD, Mark" <MCRAWFORD@lmi.org>]

Title: RE: [ubl-ndrsc] First cut on Design Document

Eve,

One problem - I have to be at a federal CIO Council XML working group meeting tomorrow morning until 12.  Will call in as soon as I can, but will be in route between the CIO Council meeting and Department of Labor so won't be able to take any notes during discussion on outline. ;-( 

Thanks for the comments, my replies are inline below -

>Position paper management: I'd like to see the names of champions put
>into the relevant section headers.

Is this during discussions, or final version?

>General style: It would be great if the blue quoted stuff could be
>attributed in some simple manner (a one-line attribution or link),
>because I'm not familiar with most of the sources you're quoting. 

Can do.  This works during discussions, but is not appropriate when we publish.  We can convert into direct quotes and footnote if we decide to keep.

>Also, this is a tiny thing, but I would prefer it if the headers were >all left aligned

I only did this for first cut to help everyone differentiate between levels.

>and if a TOC could be provided.

There is a place for it.  Will create before next version.

>Design principles: We need to put the already-agreed-on design
>principles somewhere.  Would they go in Section 3.3?  Sections 4.5-4.11? 

We need to decide on overall outline and then determine placement as occuring.

>Assuming we come up with a bunch of ranked use cases tomorrow, where >would they go?  One of these sections?

Depends on where they fit.  We need to talk about each one in context of agreed outline.

>General rules: Section 5.1 seems to take a stab at some "universal"
>rules.  Did this come from another source, or are these essentially your
>recommended positions on these issues?  I don't see any reason to keep
>these separate from the other categories of rules.  I would say that 1,
>2, 8, 9, and 10 are all "XML usage" rules.  3 and 6 are naming rules.  4,
>5, and 7 are rules about the relation between messages and BPs.  12 is >an element/attribute rule.  13 and 14 are related to datatypes.  I'm not

>sure what 15 is trying to say.  All of these categories I mention would >make dandy sections or subsections, if they're not already.

Came in part from X12 who took them from material I and others provided. Seemed to fit as high level rules, although they can certainly be divided in the fashion you suggest. 

>Section 5.2: Did these come from some other source?  If not, Mark, do
>you want to be the champion for this issue? :-)

Extracted from ebXML, Federal direction, EPA, and Department of Navy direction.  Realize this is much more structured than folks would like, but it is in keeping with how to maximize standardization.  Yes I can champion this.

>Section 5.2.2: I'm not sure that "Standardization" is unambiguous in
>this context!  I think it would be useful to have a Simple Datatypes >section that incorporates this stuff.  It's sort of about naming, but >it's mostly about enumeration.  (Then 6.9 and 6.10 could maybe go there > too.)

mostly agree.  Perhaps it would be better to general comment in 5.2.2, and provide specific in 6.9 and 6.10

>Section 6: I think "Messages" is too broad a topic on which to have a
>top-level section.  Is there a way to break it down more, so that we can
>avoid hugely nested subsections?

I agree.  Need suggestions from folks as I struggled with this.

>Section 6.7.1: I think it would be useful to distinguish between simple
>and complex datatypes.

Agree.

>Section 6.7.3: How different are 6.7.3.1 and 6.7.3.2? 

Open for discussion.  The split in 6.7.3 came from X12.  I sense they may be the same, although we could make the case that 6.7.3.1 deals more with "when allowed" and 6.7.3.2 deals with "if allowed, these are the general rules"

>Does "Standardized" in 6.7.3.3 mean "common"? 

Once again - open for discussion. 

>What does >6.7.3.4 "Categories of usage" mean?

Open for discussion.

>Documentation and appinfo: I would put a section for these in Section 6
>(as you've currently organized it), not 7.12.  It's not about features so
>much as conventions for what to put in there, so we can generate the >outputs we need.

Agree. 

>Schema feature analysis: Eventually, I imagine that we'll combine
>Annexes A and B.  I'm not sure we should actually list the test schemas; >easier and more maintainable to point to these.

Most likely.

Mark