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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


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


Thanks Fulton. I should clarify that my example of a 35-character limit
had (or should have had) a vastly different context than the scenario
you portrayed below. I should have explained further. Considering your
case 1 below:

<Quote>
If the seller's source system feeding data to a UBL dispatch advice
creation process does not itself accommodate a carrier name greater than
35 characters, the seller will have already truncated the names.
Therefore, in Case 1, the filter is irrelevant.
</Quote>

In the scenario I had in mind, this case would never happen, because
either the max element length would be changed to accomodate the
greatest length among all participants, or a different approach would be
taken that would be more specific to each trading partner's needs (such
as the approach specified in CAM). 

Having said that, your analysis is excellent, and applies to more
general scenarios.

Thanks,
Joe

Joseph Chiusano
Associate
Booz Allen Hamilton
 
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514  
C: 202-251-0731
Visit us online@ http://www.boozallen.com

-----Original Message-----
From: Fulton Wilcox [mailto:fulton.wilcox@coltsnecksolutions.com] 
Sent: Wednesday, May 10, 2006 8:32 PM
To: stephen.green@systml.co.uk; ubl-dev@lists.oasis-open.org
Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and
Restricted Data Types

All:

It is an interesting question as to how to manage constraint propagation
within and across UBL schemas. However, I think a more urgent question
is what are the impacts on the end-to-end process and on the integrity
of the data? I suggest that the schemas be left "unconstrained" and any
constrains be left to the originator's source and transaction extraction
processes. 

To give some specificity to this position, I will carry forward Joe
Chuisano's example of imposing a UBL limit of 35 characters to the
carrier name held in the UBL dispatch advice. As a benchmark, about 5%
of the 540 or so carriers listed in a Canadian Customs site are too long
to pass through the proposed 35 character or less filter. 

For example, the carrier name "Walter McDougall International Logistics
Inc"
contains 45 characters - what happens when a UBL dispatch advice
involving that carrier has to be created? What is the impact on the
process and, especially, the data. There are five principal cases, none
of them very favorable to imposing such a constraint and most
unfavorable:

Case 1 

If the seller's source system feeding data to a UBL dispatch advice
creation process does not itself accommodate a carrier name greater than
35 characters, the seller will have already truncated the names.
Therefore, in Case 1, the filter is irrelevant.

Case 2

If the seller's source system and the recipient's systems both can
accommodate the unconstrained name, but the suggested UBL 35 character
constraint has been put in place, then the results of filtering are
"bad."
Before the seller can finalize the outgoing dispatch advice, someone or
some process on the originator's side will have to truncate what is good
data, in a way that needlessly degrades the receiver's data base. Case 2
represents a "bad" outcome from a data synchronization perspective as
well as wasted effort and perhaps transaction delay.

Case 3

If the seller's system holds and can forward the whole name to the UBL
process, but the recipient needs to truncate it, and if the full name
passes through UBL (i.e., as it would today, sans field length
constraints), the "cost causer" (recipient) must do the truncation.
There is of course no assurance that the recipient needs to truncate to
35 characters: perhaps the truncation has to be to some shorter or
longer length. Shifting the work to the cost-causing recipient is the
best possible outcome for a recipient-driven constraint. Having UBL get
the cost-causer out from under this responsibility is a negative result.

Case 4

If the seller can send the whole name, but either the receiver or UBL as
a proxy for the recipient constraints forces the seller to do the
truncation, the "cost causer" shifts the cost to the originator. As
noted under case 4, there is no assurance that some a priori
UBL-specified constraint would match the recipient's systems field
length, so the sender might need to truncate the name to some in some
customized length. One of the often pernicious aspects of the "hub and
spoke" process is that the hub forces the spokes to do rather stupid
work and, perhaps some other rather stupid work as well - e.g., shift
the string to all upper case. Given that this is a power play, the UBL
filter probably is irrelevant.

Case 5

If the seller's system truncates the whole name, but the receiver of the
dispatch advice insists on receiving the whole name, the seller may be
forced to build some synonym table to be used in preprocessing data for
incorporation into the UBL dispatch advice. This is a somewhat
"virtuous"
manifestation of "hub and spoke" compulsion. Good things can come out of
hub and spoke arrangements, but all too rarely.

Conclusion,

As illustrated, there is no good, compelling case for capping string
lengths or otherwise altering the "natural" data - e.g., in which
"natural" means that the company name is the company name. Perhaps I am
missing another "case" or have mis-stated one listed.

Once filters are put in place, it becomes exceeding difficult to
eliminate them, because of the "n-way" change management process needed.
Even after the parochial interest in them disappears (e.g., through
systems upgrades), nobody will have the time or energy to figure out
whether a long-existing constraint is important to anyone, so it will
persist, potentially decade after decade.

Therefore, let the entities doing the trading enforce data disciplines
internally and in their feeder processes to UBL rather than have UBL
constrain its capabilities.


						Regards,

						Fulton Wilcox
						Colts Neck Solutions LLC


-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk]
Sent: Wednesday, May 10, 2006 5:51 PM
To: ubl-dev@lists.oasis-open.org
Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and
Restricted Data Types

I practice though (not necessarily recommended) one might just edit the
schemas to apply such a restriction artificially if the schemas are then
to be kept private. Not sure what UBL might wish to recommend about
that. If changing the namespaces this might be more acceptable (but
perhaps less useful, depending on the situation).

Can anyone explain what ATG2 recommends about such customisation,
perhaps particularly regarding datatypes? Not sure whether this is
actually customisation or just reuse of the schema artifacts, especially
if there is no change of namespace but the schemas are for internal use
only. The matter is then how to make an agreement with others to apply
such restrictions: not sure whether one should use same namespace but
edited schemas for that purpose.

All the best

Stephen Green


Quoting stephen.green@systml.co.uk:

> Hi Joe
>
> Absolutely. Sorry, I'd forgotten this and it isn't all that obvious. 
> The thing is that the datatypes UBL uses are mostly what the CCTS 
> calls unqualified. To redefine them one really (as, thankfully, Mark 
> Crawford explained earlier) has to create new datatypes based on them 
> which are called qualified datatypes. The element based at present on 
> the unqualified datatype would have to somehow be replaced, I think, 
> not being able to see how to do it any other way, with a new element 
> based on the restricted qualified datatype. To my mind it needs a new 
> element and a restricting out of the old element, rather than a 
> redefine of the old element. I can't see how to do the latter with XSD

> derivation.
> If an element was based on a UBL-qualified datatype then maybe, since 
> it would be under UBL control as it were, one could use XSD redefine 
> to restrict it. That is interesting. It may mean that restriction is 
> limited by use of an unqualified datatype, especially when CCTS (and 
> UBL) compliance is required.
> I think the same applies to the XSD substitution group method.
>
> All the best
>
> Stephen Green
>
>
>
>
>
> Quoting Chiusano Joseph <chiusano_joseph@bah.com>:
>
>> P.S. Regarding xsd:redefine: A redefine of this element (Carrier 
>> Name, represented as cbc:Name) does not seem possible (unless my 
>> dusting off of the xsd:redefine feature brings misunderstanding with 
>> it), as one would need to redefine its type, which is cbc:NameType, 
>> to have a max of
>> 35 characters rather than an unlimited number.
>>
>> However, this would cause a ripple effect across all other references

>> to the cbc:Name element within the Despatch Advice schema (through 
>> references within the Common Aggregate Components schema), which 
>> would in effect cause all other cbc:Name elements to be a max of 35 
>> characters. This may or may not be the desired outcome - even if by 
>> chance all should be 35 characters, this of course will not always be

>> the case.
>>
>> So unless I am missing something (which someone will tell me I am 
>> sure:), the xsd:redefine feature will not work in this case. All the 
>> more reason we need alternate approaches.
>>
>> Joe
>>
>> Joseph Chiusano
>> Associate
>> Booz Allen Hamilton
>>
>> 700 13th St. NW, Suite 1100
>> Washington, DC 20005
>> O: 202-508-6514
>> C: 202-251-0731
>> Visit us online@ http://www.boozallen.com
>>
>> -----Original Message-----
>> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>> Sent: Wednesday, May 10, 2006 3:41 PM
>> To: David RR Webber (XML); Stephen Green
>> Cc: ubl-dev@lists.oasis-open.org
>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and

>> Restricted Data Types
>>
>> David,
>>
>> Thinking more about CAM here: How efficient and straightforward would

>> it be to restrict the data type of - picking a schema and element 
>> completely at random here - the Carrier Name element in the UBL 2.0 
>> Despatch Advice schema to, say, a maximum of 35 characters?
>>
>> Here is the path to that element:
>> DespatchAdvice/Shipment/Consignment/CarrierParty/PartyName/Name
>>
>> Thanks,
>> Joe
>>
>> Joseph Chiusano
>> Associate
>> Booz Allen Hamilton
>>
>> 700 13th St. NW, Suite 1100
>> Washington, DC 20005
>> O: 202-508-6514
>> C: 202-251-0731
>> Visit us online@ http://www.boozallen.com
>>
>> -----Original Message-----
>> From: David RR Webber (XML) [mailto:david@drrw.info]
>> Sent: Wednesday, May 10, 2006 11:03 AM
>> To: Stephen Green
>> Cc: ubl-dev@lists.oasis-open.org
>> Subject: RE: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and

>> Restricted Data Types
>>
>> Stephen,
>>
>> I follow your thoughts here.
>>
>> We're actively re-visiting on which pieces of the CAM template should

>> be required and which non-normative / extensible.
>>
>> Right now the <DataValidation> and <ExternalMapping> are optional.  
>> Also in jCAM Martin has implemented Maven with these so they are 
>> fully extensible - but obviously that is then non-normative - but I 
>> have not yet updated the spec' to reflect that change.  It's a 
>> critical direction
>> - the realization that you cannot perscribe everything for everyone -

>> and that instead - you provide normative tools for those parts people

>> expect the standard to - while giving flexiblity - but in a known and

>> predictable and re-usable way - for those peices they traditionally 
>> expect to have control over.
>>
>> The other normative sections are of course tailorable to match the 
>> particular implementors vision and can include only those feartures 
>> and parts that suit (it's just XML markup!).
>>
>> What I would expect is that the CAM template would be a base-line one

>> - that implementors could then refine and extend to their own local
needs.
>> This I think is inline with the notion of SBS - having a jump-start 
>> kit that people can quickly use by default - and then refine and 
>> extend in practice.  Use of <include> is critical to provide 
>> separation between such base-line templates and local extensions. And

>> then context is vital for people to understand the use model for each
template.
>>
>> DW
>>
>>
>> -------- Original Message --------
>> Subject: Re: RE: [ubl-dev] Datatype Methodology RE: [ubl-dev] SBS and

>> Restricted Data Types
>> From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
>> Date: Wed, May 10, 2006 10:35 am
>> To: <ubl-dev@lists.oasis-open.org>
>>
>> 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/
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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/
>>
>> ---------------------------------------------------------------------
>> 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/
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> 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/


---------------------------------------------------------------------
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/


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