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

["Chiusano Joseph" <chiusano_joseph@bah.com>]

<Quote>
Therefore, I suggest that minimal filtering be done as part of UBL -
only that which has predicable, net value-added results.  
</Quote>

I would actually suggestion that *no* filtering be done as part of UBL
(please read on) - rather, that providing the *capability* to perform
filtering be considered, and used (or not) as implementations require.
This is consistent with the discussions that we are now having regarding
data types.

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 2:23 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



All:

In the context of boundary management between what are UBL opportunities
and obligations versus what is trading partner internal particularity, I
put together the following comments on "filtering." I suggest that
generally UBL-level filtering is at a high risk of being: 1) irrelevant
2) duplicative of other, more authoritative filters, 3) have the
opposite effect from "future-proofing" by inadvertently ruling out new
uses of UBL or complicating version upgrades.

To add some specifics:

1. From a flow perspective, transactions originate from events that
occur in a sender's particular environment and the sender-receiver's
particular trading relationship.

For example, perhaps a seller has shipped a product and needs to invoice
the supplier, or the buyer's inventory level has dropped and the buyer
needs to order from the seller. Such transactions originate in the
sender's own "particularity" and, once replicated to the receiver's
environment, live within the receiver's own particularity. In transit,
the transactions presumably live as UBL standard transactions.

With respect to transaction life cycle in terms of logical steps:

a) after detecting the "event," the sender's processes must extract
relevant transaction details, with its particularity intact,
b) the sender flows the data through what I will term the sender's
de-particularizing process to emerge as UBL-ready content,
c) the sender's processes flows the UBL-ready data through a packaging
process to create one (or perhaps more) standard UBL documents/objects,
d) the UBL transaction flows through the transport process,
e) on being received, the receiver processes the transaction through an
unpackaging process,
f) the unpackaged UBL inputs then flows through the receiver's own
particularizing preprocessors, and
g) the now particularized data flows into the receiver's internal
processes, presumably passing the receiver's essential edits.

In implementation, the above steps may not be kept distinct although it
is better from an evolutionary perspective if they are. In any case, my
assumption is that only the substance of what I describe as steps 1c, d
and e are within the UBL standards envelope. 

The question at hand is whether to inject more "filters" into UBL
transaction schemas and, by extension, into what I refer to as
packaging/unpackaging. 

2. In the end-to-end flow from sender "particularity" to receiver
"particularity" four sorts of exception conditions can arise: 

a) exceptions occur that are irrelevant in practice, because the
receiver discards the affected incoming data anyway. For example, given
a part number or customer number, often the receiving-side process
effectively will ignore related "master data" that travels with the
transaction (e.g., product description, customer name), in which how
long the strings or other characteristics does not matter.

b) exceptions occur that the receiver's processes can resolve
automatically, either from prior experiential rules or based on exiguous
data from collaboration protocols, trading partner agreements, etc. 

c) exceptions occur that the receiver's system itself cannot resolve
automatically, but that people on the receiving side can and will
handle, and 

d) exceptions occur that render the transaction inoperable to the
receiver and that must be rejected and, perhaps, subject to a retransmit
request.

Filters such as pre-specifying UBL field lengths are of no practical
benefit for cases 2a and 2b, of some benefit in case 2c and are fully
applicable to case 2d. However, "applicable" does not necessarily mean
beneficial.

3. Filter specifics as well as the impact of incorporating a new filter
within a succession of filters (those within the sender's and receiver's
systems) may create waste, difficult to anticipate backpressures and
unwanted blockages.

a) Excessively fine-mesh filters can create enough "false positives" to
negate the filters value, while loose-mesh filters permit excessive
"false negatives." Therefore, effective filter design requires a lot of
analysis and "just right" design choices which a standards body
generally cannot undertake.

b) There is risk at the transaction level from the interaction of a
multiplicity of filters. For example, if there are 10 constraints
applied to a given UBL transaction, and each of those constraints are
set at, say, at the 95th percentile, then 40% of the transactions will
be blocked ( 1 - .95 to the 10th power, assuming independent
distribution). Lack of standards adoption often results from having to
jump too many editing hurdles.

c) Intermediate filters usually duplicate the "truth" filter at that
exists at step 1g - the receiver's import of received "reparticularized"
data into the receiver's internal process. In a fully automated
environment, it costs little for a reject to occur at the "truth" level,
while it costs a lot to resolve an in-network false positive filtering
event (e.g., an order is shortstopped because of a benign field length
mismatch).

d) As an analogy, a router can switch millions of packets per second,
while an x.25 switch can switch only a few thousand packets per second
because, unlike the x.25 switch, the router is not performing deep
inspection of individual packets nor asking for retransmits from the
prior switch. Today's technology makes it cheaper and more effective to
reserve deep inspection to the end device, which then can ask for a
retransmission.

4. Anticipating preventing unwanted particularity at some thoughtfully
engineered confidence level -e.g., the 95% level - takes one into some
complex analysis and fact-finding. For those who want a feel for
"particularity" below is an ongoing dialog from and SAP-related
discussion site. The standards groups need to facilitate trading
partners, but simply cannot afford to predict and filter out their "bad"
habits, which in fact might not be that bad.

Therefore, I suggest that minimal filtering be done as part of UBL -
only that which has predicable, net value-added results. For very large
subsets (e.g., all "small businesses") much the same holds.


					Fulton Wilcox
					Colts Neck Solutions LLC



Query

My business users want to do the following on a single SAP purchase
order

1) pay for the equipment purchased in USD
2) for installation, pay for transportation in various currencies. 
3) pay service charges in local currency.

Response

To do this on one purchase order...

Enter the default currency (i.e. USD) in Vendor Master (T-Code MK02,
Purchasing Org data -> Purchasing data -> Conditions -> Order Currency).

Include a condition type for "Installation Charges". 
Use M/08 to change pricing procedure. "Item Condition" check box of the
condition type must be TICKED to allow you to enter the rate/currency in
line item. 
If you want to pay the installation charges to a vendor other than the
PO vendor, then the condition category should be "B" . select the
condition line and click on the magnifying glass icon. Change the
vendor/ currency on the next screen. Also TICK the split IV check box. 
Use M/06 to change/ create condition type.









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


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