RE: Sample Pacakged Messages for RR Browse and Drill Down in Trac k 1

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

> First of all, thank you for taking the time to put these 
> together.  They
> have come in quite handy in a number of ways.

I second this! 
> 
> 1.  You are missing the version 0.21 (or 1.0) in the 
> Content-Type header

I am not doing anything with version. What version level
do people using it need?

Shouldn't there also by a "charset" parameter/attribute?
(It should not be on the "Multipart" content-type header,
according to TRP list). What value for charset --"UTF-8"?

> 2.  You are missing the xmlns attribute off your ebXMLHeader element

XML Authority (hope it is) says about RegRep0.8.dtd that
the attribute "xmlns" should not be declared. So it thinks
the dtd is slightly broken...  

I am using Xerces for SAX2 functionality. The Xerces documentation
warns about interop problems caused by having DTDs that omit
"xmlns"  while proceeding to use the attribute in instances.
(This contrasts with the XML Authority view, of course.) 
Xerces notes say some parsers may complain about the presence
of "xmlns" when undeclared. (Xerces so far does not 
apparently because it tries to be schema capable)
I have no idea what others are doing in the current mixed dtd/xsd
environment.
People can possibly dance around issues by setting parser features
and properties, but I think I would like to hear
discussion of our options. Maybe we should just omit the attribute
from both the dtd and the instances until this particular
gotcha gets ironed out. I think both specification content and 
operational/implementational status need to be factored in
for the Tokyo POC agreement.
 
> Two outstanding questions to all POC'ers:
> 
> 1.  Should the name of the Action be 
> getRootClassificationNodesRequest or
> getRootClassificationNodesAsync?  I believe it should be the 
> former based upon my interpretation of the Reg/Rep spec.

I hope that the names for Registry service do not include
any suggestion about how they have been transported. So
I definitely favor using the simple ServiceRequest and ServiceResponse
convention for names. 

I also have a question about how
to select the response value for DocumentLabel and Action.
I am using what I take to be the definitive request information--
the actual element tag from the request XML (after all, the header
may not match the payload, and I think implementationally it is better to
just note/log a discrepancy and try to return an appropriate
response to the actual request. But in general, should the MS layer
rely on the info in the received header when responding? Or should the
MS layer just presume that these values are always supplied from the
"business/higher" layers? I think this question should go back to
TRP and be addressed in their "Services" document (where all protocol
stack interfacing issues get dumped.)

 
> 2.  Should we be using the ReceiverURI element in the 
> RoutingHeader as the URI where to send the response? 

Good question. I was doing a lookup in the barebones
CPA database info I have (select URL from ... where DUNSId =...)
Are the specs saying we take this info off the header
dynamically? 

I would think Chris Ferris would be saying no to this!