Comments on: Very Rough Draft of Header Specification

["Miller, Robert (GEIS)" <Robert.Miller@geis.ge.com>]

Hi David,

Looks like your team is making nice progress.  Here is my initial feedback.

Question: Why is 'Message Routing Info', which apparently may contain two
kinds of information:
	- Path that should be taken by a message
	- Path that was taken by a message
not separated into two separate documents?  It seems to me that one might
want to 'sign' the 'should be' path, and that handling of the two distinct
message parts would be made easier if the two were in separate documents.
If 'path taken' is made separate, should 'path should be' be a separate
document or be folded into MessageHeader?  Just food for thought.

Editorial: 3.1 first sentence suggest change 'bare minimum' to something
like 'essential information', since 'bare minimum' implies to me that
'response addresses' should not be in 'MessageRoutingInfo' since it is
optional (ergo not bare minimum)

Comment: 3.1 MessageHeader 'Version=x.x'

In the world as we used to know it, I was a strong advocate for version
numbers.  In the new internet world, I consider version number references
outdated, replaced instead with URx's, which not only support versioning,
but which also support location of the underlying definition of the version.
I would keep version numbers in the underlying definitions of course. 

Editorial: 3.1 last sentence - remove comma after 'specified'

Editorial: 3.1 - 3.4 Level i Headers

	When I started reading 3.2, I got confused.  In the Level 1 seciton,
I interpreted what I saw as 'MessageHeader' and 'MessageRouting' are the
'level 1 headers'.  I think my confusion would have been avoided had the
term 'Headers' been something like 'Header Service Elements' (wherever
'header(s)' appears).

Editorial: 6.3.1 Why are 5) through 8) in bold?

Question: 6.5.2 4) Should Message Routing History be 'required', or be an
optional requested service? (I don't know what is common practice)

Editorial: 7 Data Dictionary <EdNote> 'enumeration of codes values'

	FYI, I'm not a supporter of 'code values' in XML representations.
Instead, I support 'codelist elements', which accomodate much
stronger semantic defintion of the code meanings.  Each code (and/or code
name)is defined as an element in the Namespace of the code list,
which Namespace is made the default Nmaespace by the embedding element.  For
this reason, I would prefer 'codelist definitions'.

	Example:
<ServiceQualityRequested><normal/></ServiceQualityRequested> 
	  where the DTD entry for <ServiceQualityRequested> establishes the
Namespace for the codelist definitions, and each codelist element definition
is defined in its appropriate codelist namespace.

Cheers,
        Bob