OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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