[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cam] Outputs
Peat wrote: >I am sure that the OASIS email system is not going to post >this, but if my email gets to the three of you this is good >enough. > >I would expect that CAM: > >- allows for validation >- allows for transformation >- allows for linking assignments > > mm1: Correction ......c/latter/former That doesn't include presentation, correct which is being addressed in another venue. >- Bruce > > >---- Original message ---- > > >>Date: Thu, 24 Jul 2003 12:48:07 -0600 >>From: Monica Martin <monica.martin@sun.com> >>Subject: Re: [cam] Outputs >>To: martin.me.roberts@bt.com >>Cc: Gnosis_@compuserve.com, cam@lists.oasis-open.org >> >>martin.me.roberts@bt.com wrote: >> >> >> >>>David and Others, >>> If the CAM is going to be used to output info as well >>> >>> >as > > >>>validate input, A very wide spec I think, but we may well >>> >>> >at least think > > >>>big what about the following: >>> >>> We have Assembly structures that describe how >>> >>> >something looks. > > >>>We have rules that describe the effects of context on the >>> >>> >input file. > > >>>Why not use the same analogy for output. >>> >>> We current define an output set of rules but not >>> >>> >directly linked > > >>>to a structure. What about defining in the External >>> >>> >Mapping section a > > >>>Structure and a set of rules. >>> >>> >>> >>mm1: Doesn't this have to do more so with the output for >> >> >presentation or > > >>for processing? If the latter, I believe this is already >> >> >being addressed > > >>in other groups. >>Thanks. >> >> >> >>> Also this would work well with the mail merge view of >>> >>> >the world > > >>>where the input fields could be named, or given ids or >>> >>> >aliased and then > > >>>these could be used in the output structure which would >>> >>> >reduce the > > >>>rules. >>> >>> So we could have: >>> >>> AssembleStructure as: >>> >>> <Order> >>> <Header> >>> <OrderDate>$OrderDate</OrderDate> >>> <Buyer>$BuyerID</Buyer> >>> ... >>> </Header> >>> <Body> >>> ... >>> </Body> >>> </Order> >>> >>> Output would be: >>> >>> <PurchaseOrder> >>> <POHeader Date="$OrderDate"/> >>> <Party function="Buyer" >>> >>> >ID="$BuyerID"/> > > >>> .... >>> >>> I think you can se my logic. >>> >>> The restrictions on this are: >>> >>> 1) Only transformations based on input data >>> >>> >are allowed. > > >>> 2) Only one data input is supported (may be >>> >>> >need to > > >>>allow referencing of ebXMl and Soap attachments for >>> >>> >examples) > > >>> 3) Aliases or XPATHs in to input would be >>> >>> >supported. > > >>> 4) Output rules include functions such as >>> >>> >substring etc. > > >>> I can see this being really powerful. >>> >>>Martin Roberts >>>xml designer, >>>BT Exact >>>e-mail: martin.me.roberts@bt.com >>>tel: +44(0) 1473 609785 clickdial >>>fax: +44(0) 1473 609834 >>>Intranet Site :http://twiki.btlabs.bt.co.uk/twiki >>> >>>You may leave a Technical Committee at any time by visiting >>> >>> >http://www.oasis- >open.org/apps/org/workgroup/cam/members/leave_workgroup.php > > >>> >>> >>> >>> >> >>You may leave a Technical Committee at any time by visiting >> >> >http://www.oasis- >open.org/apps/org/workgroup/cam/members/leave_workgroup.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]