RE: The role of context in the re-usability of Core Components an dBusiness Processes - OR Say What???

["Blantz, Mary Kay" <mblantz@netfish.com>]

Hello,

1.  My take on Phil's 'Total' view is that it could be beneficial in some
    ways, such as a supplier would only have to send it in one way and the
    receiver could pick and choose which parts they required.  We wanted to
    do that with X12 transactions, but many receivers set up their 
    translators to compare on their specifications, rather than the 
    total transaction set.  In addition, since we are trying to develop
    'lean and mean' XML for the SME's, the fewer pieces of information we
    need to send, the better.

2.  Yes, Phil, we could easily be inventing a Tower of Babel if we are not
    careful.  The UID described by Core Components is our effort to make
    sure that doesn't happen.  Or, at least, may sure that their is a
    common way for all the 'languages' to interoperate.

3.  As for 'pigs flying' as part of context, given the current animal 
    health problems in Europe, I sure do hope that pigs can't fly! :)

4.  Wearing my AIAG hat, I would like everyone to know that AIAG is very
    actively working with other industry groups, and will ebXML and X12
    and EWG, and is trying very hard to avoid industry specific requirements
    if they are not genuinely industry specific.  MRO Purchasing, for 
    example, seems as though it should be identical across industry
    boundaries.

Mary Kay


-----Original Message-----
From: Philip Goatly [mailto:philip.goatly@bolero.net]
Sent: Thursday, March 15, 2001 10:00 AM
To: William J. Kammerer; ebXML Core
Subject: Re: The role of context in the re-usability of Core Components
and Business Processes - OR Say What???


Folks,

1.I wonder if there is not a case for having a 'Total' view of say address -
including anything that is needed in virtually any context UK,US, Outer
Mongolia etc. and having a mechanism for a View of the 'Total' which
switches off what is not needed ?

2.You might like to consider the consequences for interoperability if  one
allows one business entity to decide in isolatino what he/she needs - are we
not reinventing the 'Tower of Babel' ?

Cheers, Phil
----- Original Message -----
From: "William J. Kammerer" <wkammerer@foresightcorp.com>
To: "ebXML Core" <ebxml-core@lists.ebxml.org>
Sent: Thursday, March 15, 2001 5:43 AM
Subject: The role of context in the re-usability of Core Components and
Business Processes - OR Say What???


> I have taken another look at the ebXML specification: The role of
> context in the re-usability of Core Components and Business Processes,
> Version 1.01.  I'm making a confession: I still don't get it.
>
> Okay, so I've got a procurement process, and I'm dealing with paint, and
> I'm in the U.S, and I'm selling to somebody in France, and it's Tuesday,
> and pigs fly, and this thing is going to apply these "contexts" to come
> up with.... what?? A schema? Is this being used to build message schemas
> (as opposed to document instances) on the fly?  Do these rules determine
> what's included as XML elements at execution time when the message
> instance is built?
>
> I have a suspicion that this "context" stuff is a little too complex,
> and perhaps unnecessary.  Most of this kind of stuff should really
> devolve on the application and the people who know the business the
> best.  And, besides, "context" isn't really what causes people to have
> conniptions when using EDI - they know full well that they need a state
> or province code when sending U.S. or Canadian addresses, or that a VAT
> (tax) is not used in the U.S., or that they have to add some sort of
> hazard designation if so required - or send a separate MSDS - or that
> they have to put junk in there for customs if going over the border,
> etc. etc. What makes us think we know the application better than the
> business using ebXML?  The problem with EDI is figuring where the heck
> to put in the VAT - what segment? in the detail or the summary or both?
> What code means "VAT" once I find the segment?
>
> Confusion sets in when I read Line 141: "Another [rule] specifies that
> if the seller is in France, the product description (in French) shall be
> included [in invoice line items.]"  Why?  The seller isn't going to be
> reading  the invoice - the buyer does. Is this just a boo-boo? - as the
> sample context had the BUYER in France.
>
> In any event, the product description should be in the preferred
> language of the buyer, if that's possible.  But it's not necessarily
> the predominant language in the buyer's country;  a U.S. buyer may want
> the description in both English and Spanish, and so you can't just have
> a simple context rule based on the country code of the buyer's ship-to
> location.
>
> Maybe this kind of stuff ought just be business rules in the
> application - the customer file would say what languages he prefers for
> the product description, if any.  The "if any" is important - a SME or
> consumer may always want a product description, but a shop with
> sophisticated IT capabilities would rather forgo it, as they would load
> a catalog with product IDs and descriptions and be able to retrieve the
> descriptions themselves.  Sure - these decisions seem like a lot of
> effort, but that's why they call it "work." There's no reason for us to
> take on application work - and do a half-assed job of it in the
> process - all the while putting the user in a straight-jacket.
>
> Now, I'll be the first to confess that I don't really understand how the
> business process model correlates with the business documents to be
> exchanged.   Referring to Line 498, section 6.9 (Role Context), I have
> this vague impression that the business process mandates that I have
> both a buyer and seller, which will result in party definitions for
> each. So far so good - that kind of correlates with how I think of a
> Purchase Order.
>
> But I'm really thrown off with that business in Rule #3 about specifying
> the preferred carrier - is this done when generating the schema to be
> used, or when I generate the document instance?  Isn't this a decision I
> might make on the fly, in the application, depending on all sorts of
> scenarios: maybe I have a preferred carrier only if it's FOB origin, or
> it's LTL and bigger than a bread box, or whatever strange gymnastics
> attend.  I'm having a hard time differentiating when business rules
> leave off and when and this strange thing called "context" takes over.
>
> Help me out. Are we writing specs for an ERP system here?
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>


------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org