Re: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and Restricted Data Types

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

This makes me think UBL might be benefitted
from CAM templates based on a profile of CAM
which covers the gaps. Maybe one profile 
without the 'context' bit (CCTS concept of it, 
not CL methodology concept of document context)
and one with (so one doesn't have to 
implement a full-scale CCTS context-sensitive
system unless there is a need to). There may
be other bits of CAM not needed in such UBL
implementations too, or parts which UBL 
duplicates which could be profiled-out.

Stephen Green

>>> "David RR Webber (XML)" <david@drrw.info> 05/10/06 15:02 PM >>>
Chin, 

I was trying to not get into nitty-gritty angle bracket stuff - but
here's a 20,000 foot view. 

The CAM template consists of 5 sections: 

<Header>
<AssemblyStructure> 
<BusinessUseContext> 
<DataValidations> 
<ExternalMapping> 
  
We can equate the two <AssemblyStructure> and <BusinessUseContext> to
the layering approach - where UBL provides the structure definition -
and the context section then exposes the delta between the generic and
subset.  You can use <include> in the structure section to reference a
particular UBL sample. 
  
Basically if you look in the <BusinessUseContext> section and you see
nothing - then you know people are using that included UBL sample
as-is! 
  
Otherwise - the Header can come into play next - because that is where
you define your global context variables that you might need - for
example boolean $export_order. 
  
So - in the context section you can have default rules - I would expect
you to have these normally - as these apply to all context instances
and use - these are identified in the XML by -  
  
   <Rules><default><context> <!-- default rules --> </context>/default>
.... 
  
After that - you have specific context rules - here is where you would
put the typical refinements and crosschecks (e.g. if $export_order then
<export_manifest> required mandatory element, etc) associated with your
use case - these can reference global $ variables - or be value driven
within the data stream - e.g. : 
  
  <context
condition="PHS398_ResearchPlan:TypeOfApplication='Resubmission'"> 
    <constraint action="makeMandatory(//RR_SF424:FederalID)" />  
    <constraint action="setLength(//RR_SF424:FederalID,15)" />  
  </context> 
</Rules> 
  
So you can see the deltas are explicitly called out and labelled by
context - and you can find them quickly without having to grope through
the XML structure itself line-by-line.

CAM also provides you with a library of 30+ functions - so you can
manipulate the structure tree - pruning or selecting, changing from
optional to mandatory, etc, rule driven.  I like to say that XSD schema
provides you with a picture map of all the possible structural varients
that you may encounter - whereas CAM restricts this to the exact
structure layout that you need for your particular context and usage.

DW


 -------- Original Message --------
Subject: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and 
Restricted Data Types
From: Chin Chee-Kai <cheekai@softml.net>
Date: Tue, May 09, 2006 9:21 pm
To: UBL-Dev <ubl-dev@lists.oasis-open.org>

Hi David,

Very much so, certain level of semantics processing that is common
may be extracted and stored away as what you call sub-component
templates.

You mentioned that CAM already handles the deltas by making them
explicit so business users can readily inspect them.  It sounds good,
but in what manner does CAM store and manifest the deltas?  Let's
say we use the string length restriction from infinite to 30-char
for example.  How does CAM indicate this delta?   (Sorry for asking
something so simple relative to CAM as I haven't much exposure to
CAM yet).   If he way CAM does it is usable, there may be something
which UBL customisation could incorporate.


Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6820-2979
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Tue, 9 May 2006, David RR Webber (XML) wrote:

>>Chin,
>>
>>...
>>
>>Another tool here is <include> statements.  Where a template fragment is
>>created that handles default processing of common blocks of XML content
>>(address is an obvious one).  Being able to create sub-components
>>templates - breaking the overall processing down into smaller more
>>manageable chunks is another notion that helps to implement concepts
>>such as SBS.
>>
>>DW
>>


---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the
UBL OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/ 


---------------------------------------------------------------------
This publicly archived list supports open discussion on implementing the UBL OASIS Standard. To minimize spam in the
archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Alternately, using email: list-[un]subscribe@lists.oasis-open.org
List archives: http://lists.oasis-open.org/archives/ubl-dev/
Committee homepage: http://www.oasis-open.org/committees/ubl/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/