Re: [Issues-TRP]

[christopher ferris <chris.ferris@east.sun.com>]

Himagiri Mukkamala wrote:
> 
> THe first three issues are related to earlier email about
> SOAP/Apache by Sakata Yuji
> 
> 1) Always have a manifest element - This is cause Apache
> does the  invoke based on the first child of the SOAP
> body element and sometimes messages may not have a manifest
> element. Hence all ebXML messages should have a Manifest element.

This would be counter to the spec. Just because the Apache SOAP2.1 processor
doesn't handle Header entries correctly seems a poor excuse to
violate the spec. There are few cases I can think of when there
isn't something from the TR&P namespace in the Body element.

> 
> 2) Stick to "eb" as the namespace prefix for all ebXML elements.

This should make no difference what-so-ever unless there are
some using non-namespace aware XML parsers.

> 
> 3) There will be an empty payload mime body part for messages
> without payload. This is cause apaches' implementation does'nt
> write messages as multipart/related if there are no multiple body parts.

Seems reasonable. I would suggest a consistent mime type for the
null payload.

> 
> 4) PartyID: The example around the the element definition in
> the TRP spec shows as type"urn:duns.com" and the actual value
> as the TEXT_NODE. But in the example at the end of spec, it's shown
> as TEXT_NODE with value "urn:duns:111111" with no
> type attribute. This needs to be clarified.

There is no formal URN scheme for DUNS numbers (as has been hashed
to death on the TR&P list). I would recommend that you just pick
something and go with it for purposes of the POC.

> 
> 5) Agree on where the DUNS number comes from. Use some
> arbitrarily assigned numbers ?

You could make them up, or each vendor could use their
own (assuming they all have one). You can look it up if you
don't know it off hand. 
	https://www.dnb.com/product/eupdate/update.htm

> 
> 6) There are some issues with IBMs' implementation of XMLDSIG
> which ralph pointed out. This needs to resolved by this week or
> else XMLDSIG may not be used.

Agreed, we need to get this resolved.

> 
> 7) Where Schema and DTD exist, use schema as the standard.

Agreed.

> 
> 8) Use specification as the source of information, if there is a
> discrepancy between the spec and the sample. But need to
> convey that to the working group.

Agreed, and the sooner the better;-)

> 
> 9) All the business level conversations will be asynchronous as
> the demo has user interaction.
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-poc-request@lists.ebxml.org