ebxml-iic message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [ebxml-iic] Re: comments on new test material
- From: Michael Kass <michael.kass@nist.gov>
- To: Jacques Durand <JDurand@fsw.fujitsu.com>
- Date: Wed, 25 Sep 2002 16:18:18 -0400
Jacques,
I missed this item in my response to your previous message.
At 03:50 PM 9/23/2002 -0700, Jacques Durand wrote:
- just a matter of format: The
arguments for SetPayload, (Content-Type =..., COntent-Id =...) should be
treated
like any other "message
expressions" (so should be in this field, like the XPath
expressions).
I believe the the MIME header manipulation should not be folded into the
<Condition> MessageExpression </Condition>
content for 2 reasons.
1) The <Condition/> content purpose is the manipulation of message
templates. The message templates will be
SOAP messages with embedded ebXML content. The same will be true
for payload content ( in most cases ).
Mixing in MIME header values I believe confuses the issue. In one
case, we are using XPath-like syntax to describe
the manipulation of an XML document object, next we're manipulating
non-XML MIME headers. I understand that we
are defining "abstract" tests, but again, there are
implementation issues that we should consider, and I believe we
should
try to model our abstract tests along the object-oriented lines that will
define our XML schemas.
I believe that manipulating MIME content at a higher
level ( the <SetMessage> and <SetPayload> levels ), as
well
as <GetMessage> and <GetPayload>... (for retrieving those
values) makes more sense from an ultimate "implementation
perspective". Since MIME headers hierarchically are higher in
the message construction schema, and do not use XML
semantic rules for manipulation, we should not try to describe their
manipulation in an XML pseudo-language. I
believe that they are better off treated as name/value pairs in their
respective object classes (Set/GetMessage, Set/GetPayload).
It is a natural place for them to be described. In addition, some
of the other attributes ( such as "retriesReceived",
"numberOfDuplicates"...etc... can and should also be addressed
at this level. I will try to illustrate my case by using
example
#3 of our Abstract Tests:
<TestCase name="All MIME parts must have a CID or
Content-Location MIME header">
<TestStep>
<PutMessage
templateRefId="mhdr_0">
<SetPayload
Content-Type='text/xml' Content-ID='cid:payload_1'
TempateRef='mpld_basic'>
...
if we needed to manipulate payload XML content.. we'd do it here... say
for REGISTRY testing ........
...
but for this test, we're just manipulating MIME headers
</SetPayload>
/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:Action=’Reflector’
and/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:CPAId=$CPA_Id
and/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:ConversationId=’$ConversationId’
and
/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:MessageData/eb:MessageId=’$MessageId’
and
/SOAP:Envelope/SOAP:Header/eb:Manifest/eb:Reference/@xlink:href="">
</PutMessage>
</TestStep>
<TestStep
name='Search received messages'>
<GetMessage>
<Condition
>
$MIMEMessageContent-Type
== ’multipart/mime’ or $MIMEMessageContent-Type !== ’text/xml’
</Condition>
<Condition
errorStatus='fatalTest'>
($MessagePackageContent-Location
!='’ or $MessagePackageContent-ID !=‘’) and ($PayloadContent-Location
!=‘’ or $PayloadContent-ID != ‘’
</Condition>
/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:CPAId==$CPA_Id
and/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:ConversationId==’$ConversationId’
and
/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:MessageData/eb:RefToMessageId==’$MessageId
</GetMessage>
</TestStep>
</TestCase>
I believe that moving MIME header definitions into <Condition>
content would confuse what is really a clear delineation in
functionality.
Plus, assuming that ( for implementation ) we end up using some type of
template manipulation language, such as XSLT or XUpdate ( which are
designed to support XML document manipulation ), we cannot use those
engines to manipulate MIME headers in any kind of a reasonable way.
"MIMINIG UP" of a message should occur outside the scope of XML
template manipulation, in my opinion.
Comments?
Mike
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC