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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-cppa] Proposed Pim-Requested schema enhancements for MessagingCharacteristics and BusinessTransactionCharacteristics


Here is a Q&D xslt that worked in oxygen 7.2 on latest cppa. Change namespace values if using 2.x versions

This is just for DeliveryChannel but similar scripts would pull out other multiple element ranges.

 

Dale

 

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

        xmlns:xlink="http://www.w3.org/1999/xlink"

        xmlns:tp="http://docs.oasis-open.org/ebxmlcppa/cppa-3.0" version="1.0">

        <xsl:output method="xml" omit-xml-declaration="yes"/>

        <!-- get rid of text output -->

        <xsl:template match="text()"/>

        <!-- start here -->

        <xsl:template match="/ | *">

                <xsl:apply-templates/>     

        </xsl:template>

        <xsl:template match="@*"/>

        <xsl:template match="tp:DeliveryChannel">

                <xsl:copy-of  select="."/>

                <xsl:text>

</xsl:text>

        </xsl:template>

</xsl:stylesheet>

 


From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Thursday, August 17, 2006 7:57 AM
To: Dale Moberg
Cc: OASIS ebXML CPPA TC
Subject: RE: [ebxml-cppa] Proposed Pim-Requested schema enhancements for MessagingCharacteristics and BusinessTransactionCharacteristics

 

Dale,

 

Duh!  Many thanks for pointing out the obvious.

 

It's clumsy - but it may work - e.g.

 

Nesting xincludes - where some of those nested xincludes have just one element in them - getting around the issues...

 

I'll try some test samples with OxygenXML and see if it works OK!

 

Will report back later today or tomorrow morning...

 

Cheers, DW

 

-------- Original Message --------
Subject: RE: [ebxml-cppa] Proposed Pim-Requested schema enhancements
for MessagingCharacteristics and BusinessTransactionCharacteristics
From: "Dale Moberg" <dmoberg@us.axway.com>
Date: Wed, August 16, 2006 4:25 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "OASIS ebXML CPPA TC" <ebxml-cppa@lists.oasis-open.org>

Hi David,

 

Does your xinclude implementation have support for range inclusion? (see the example C.5 in http://www.w3.org/TR/xinclude/)

 

Your problem cases all seem to be with elements that can be included more than one time. You want to have a “wrapper container” to let the tool spot the list.

But you should be able to pull out the range using an xpath with array indices for the first and last elements.

 

If I have some time later today, I can try to work up an example using xslt.

 

Dale

 


From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Wednesday, August 16, 2006 12:03 PM
To: Dale Moberg
Cc: OASIS ebXML CPPA TC
Subject: RE: [ebxml-cppa] Proposed Pim-Requested schema enhancements for MessagingCharacteristics and BusinessTransactionCharacteristics

 

Dale,

 

Looks good and elegant.

 

What I was discussing to support use of xinclude inside of PartyInfo - seems inherently gnarly - since its tripped up by the notion that most things are standalone elements with 1 ... oo on the occurance model - and then linked via REFids.

 

It works coincidently for Transport and others that have ability to have more than one occurance of the child components within their parent element.

 

This is a bit frustrating!

 

I guess the original notion was too flexible!

 

If we accept what we have now it restricts what you can do with xinclude - but if we start adding parent elements to facilitate xinclude - then by rights we have to add these to all the top level elements within PartyInfo if we are going to be completely consistent about it.

 

Heavy sigh.

 

If the xinclude was just more intelligent - so you could for instance have a <xi:dummy> root element - that was ignored - this would make life so much easier.  Of course getting that approved by W3C would taken an eon.

 

So its back to adding just a couple of parent elements - where they are typically most needed -

<tp:DeliveryChannels>,

<tp:mshOverrides> and

<<tp:mshPackages>

 

since for the others the typical use pattern is actually 1:1 there.

 

We could also redefine the schema model - so that both forms are permitted - the 2.x and this new one - which would ensure backward support of course.

 

But then we may just decide - given the other changes that will require mod's to 2.x CPAs to match 3.x - that we may as well grasp the thorn completely in the interest of making networks of CPAs much easier to support and upgrade in future by exploiting what xinclude can give us...?

 

Thanks, DW

 

-------- Original Message --------
Subject: [ebxml-cppa] Proposed Pim-Requested schema enhancements for
MessagingCharacteristics and BusinessTransactionCharacteristics
From: "Dale Moberg" <dmoberg@us.axway.com>
Date: Wed, August 16, 2006 11:45 am
To: "OASIS ebXML CPPA TC" <ebxml-cppa@lists.oasis-open.org>

Hi,

 

I have used the same procedure for allowing MessagingCharacteristics and BusinessTransactionCharacteristics to be referred to and to be placed as children of a CPP or CPA root element. BusinessTransactionCharacteristics may need an extensible model to handle TimeToPerform, and so support for that has been added (and will eventually be tested.)

 

So here is a view of the changes (the CPAType is basically the same):

 

 

For MessagingCharacteristics, we would then have

 

 

 

and the type information

 

 

To summarize this (and omit the extensibility apparatus detail), the main additions are to the attribute groups, messagingAttributes and businessTransactionAttributes. Each of these groups gets an @id and @idRef attribute of type xsd:ID and xsd:IDREF, respectively. The modeler can then omit all the attributes except @idRef and thereby refer to a child of the root element (either CPP or CPA).

 

I will investigate putting these alternatives into a choice construct to see if the flavors of MessagingCharacteristics and BusinessTransactionCharacteristics can be made more modular. I have checked the schema changes against the main examples used to illustrate the schema usage, and 2.0 instances can be updated to 3.0 instances by changing the namespace (and removing the cppa namespace prefix on attributes, if present).

 

I am attaching a zipfile snapshot of the examples and the 3.0 schema.

 

Remember that several more changes need to be made (such as ebMS 3.0 support and ws-policy inclusion) and all the 3.0 annotations need to be added. However, the schema has moved quite a ways from 2.0 versions, and you might wish to comment on it in even an incomplete state.

 

Once the schema seems stable for the current enhancements, the document will need updates accordingly.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]