RosettaNet signal dtd's

[John Yunker <JohnY@EDIFECS.COM>]

Karsten, per your request here are the DTDs for AcceptanceAcknowledgment and
Exception.  I have included the message guideline as well for better
understanding of the structure.

Please note that I have added a block "OffendingMessageContent" to the
exception to allow explicit identification of the message element(s) that
are in error (unacceptable to respondent).  In this block is the ability to
identify the XML content addressing language used (e.g. XPATH), as well as
any number of explicit errors.  Each error has an XML content address, plus
both a free form error description and the OCL validation constraint that
failed.

If you look in the message guideline you will notice that I allowed for both
"XPATH" and "human readable" for xml content address for implementations
that want to communicate specific errors but do not support XPATH. Of course
we could add a code for any sufficient xml content addressing syntax.

The OCL element "ValidationConstraint" is provided for automated negotiation
of content (e.g. the sender may have a range of acceptable values for
shipping method, but the one sent is not acceptable to the responder...  by
allowing the responder to provide the validation constraint a mutually
acceptable result may be arrived at without human intervention.  In the case
human intervention is required the constraint could have already been
pre-processed...)

Please let me know of any concerns...

Thanks,
John



-----Original Message-----
From: Karsten Riemer [mailto:Karsten.Riemer@east.sun.com]
Sent: Thursday, March 15, 2001 12:57 PM
To: ebxml-bp@lists.ebxml.org; ebxml-core@lists.ebxml.org
Subject: RosettaNet signal dtd's


Hi,
In specschema 0.90 we had included RosettaNet RNIF 1.0 dtd's as the
recommended dtd's for business signals. For specschema 1.0 we need to at the
very least update these to the much simplified RNIF 2.0.

A couple of questions before I do so:

1. Does UMM have a set of signal DTD's we should use instead.
2. RNIF 2.0. does not have an acceptanceAcknowledgement. Should I just clone
the RNIF 2.0. receiptAcknowledgement? 3. Should we include the generic
notification of failure? (This is not a signal, but a generic Business
Document to notify another party about a failure). 4. Does anyone in core
components have suggestions how to use core components in any of these
signals, they have tags like telephone number etc. in them.

Attached are the two signals receiptAcknowledgement and exception, and the
notificationOfFailure.

thanks,
-karsten

AdditionalEbxmlSignals.zip