Re: [ebxml-cppa] CPPA Version 1.05

[Tony Weida <rweida@hotmail.com>]

Duane,

Some clarifications, within <TW> tags ...

Cheers,
Tony

----- Original Message -----
From: "Duane Nickull" <duane@xmlglobal.com>
To: "Tony Weida" <rweida@hotmail.com>
Cc: "CPPA" <ebxml-cppa@lists.oasis-open.org>; "'Ebtwg-Ccs (list)'"
<ebtwg-ccs@lists.ebtwg.org>
Sent: Friday, January 25, 2002 6:14 PM
Subject: Re: [ebxml-cppa] CPPA Version 1.05


> Tony:
>
> More responses in line: (I have cc'd the CC team so they may add
> comments too since this CPP/A issue affects whether or not context will
> be implementable.
>
> > > Tony et al:
> > >
> > > Will the comments regarding the link to a recognizable XML format for
> > > the Party details be addressed at the face to face? (ie - necessary
for
> > > context to be implemented).  HTML is NOT acceptable for this.  What
> > > happens if I were to write my party information in HTML using
characters
> > > that you can;t read (ie - Japanese Kanji, Korean, Hebrew etc.).
> >
> > Issue 151, Specify type for PartyRef, was targeted for consideration
during
> > the version 1.1 time frame and will be discussed at the F2F.
> >
> > A CPP author can already identify a type according to the current spec.
> >>>>>>>>>
>
> I don't think I got my point accross.  I am talking about the type of
> XML Schema that is used to describe the Party details.  If I am writing
> a program to grab someones' physical address and country,  I need to
> know the structure and enumerated values possible for this information.
> That is not currently available.

<TW>
The PartyRef element's type attribute sets the stage for that -- it can
identify an XML schema for reference details about a party.  The CPPA team
has not recommended a particular schema for that purpose (so far), but
remember that we've necessarily focused on the primary purpose of CPPs and
CPAs -- to enable configuration of business-to-business systems for
interoperation.  Things like phone numbers and street addresses are clearly
useful, but still decidedly secondary considerations relative to that
purpose.
</TW>

> A "Type=DUNS" does not allow me to programmatically access anything.  It
> is a very bad model.


<TW>
You're confusing PartyId and PartyRef, two different elements with two
different purposes.

A PartyId element identifies the party itself.  Each party can have multiple
PartyId elements.  DUNS is one very common way of identifying businesses.
Therefore, "type=DUNS" is a fine example (among others) for the PartyId
element's type attribute.

The PartyRef element identifies an external document with additional
information about a party -- its type attribute specifies the external
document's type.
</TW>

> > If the type is not identified, then by default (and only by default) the
> > referenced document must be HTML.
> >>>>>>>>>
> Currently the instance has the following structure:
>
> <tp:PartyId tp:type="DUNS">123456789</tp:PartyId>
> <tp:PartyRef xlink:href="http://CompanyA.com/about.html" />
>
> Sure - the xlink can be XML but what type of XML?

<TW>
Again, that's what the PartyRef element's tp:type attribute is for (it has
nothing to to with the type attribute of the PartyId element).  Consider the
example from the CPPA spec:

<tp:PartyRef xlink:type="simple"

    xlink:href="http://example2.com/ourInfo.xml"

                     tp:type="anyURI"/>
</TW>

> If you follow the
> xLink and find this:
> <g3x>
> <fgdl> fudd </fgdl>
> <d44f> more fudd <d44f>
> </g3x>
>
> What are you going to use for my country code to drive the geopolitical
> context of core components at Design time?  This ugly XML may seem
> unlikely to you and to me, but for an application, there must be some
> way to pass on the semantics of the address.
>
> *Brilliant Idea* !!!
>
> Work with the CC team and use the ebXML Core COmponents for Party
> Details.  At least you will not have the CC team coming back saying they
> can't understand the party details XML.  We should eat our own dog food
> too.
>
> > Personal opinion: if a CPP author chooses to use HTML and some natural
> > language that I don't understand, that IS acceptable -- even if you or I
> > might feel that "better" choices are available.  Anyone who finds it
> > unacceptable can, of course, take their business elsewhere.
> > >>>>>>
>
> I completely disagree.  I find this a poor attitude - "If you don't like
> it, go use something else".

<TW>
What are you completely disagreeing with?  I specifically agreed with you
that better choices than HTML may be available.

And who are you scolding for a poor attitude -- my hypothetical CPP author?
If she chooses to use an XML schema for party reference information, that's
great.  But if HTML meets her needs and she prefers HTML, that's okay too.
Beyond question, anyone who finds her choice unacceptable can deny her their
business, but any suggestion that she has a poor attitude because she
prefers HTML is without foundation (after all, she doesn't really exist :-).
</TW>

> We are here to represent businesses and we
> must make ebXML meet the needs of businesses.  YOu have all done such a
> great job so far and CPP/A is very, very close to being finished.  We
> need to know the geographical information to drive the context
> mechanism.  It simply doesn;t work without it.  Here is an example:
>
>     * »êÀÚºÎ, 2002³âµµ EC±â¼ú°³¹ß»ç¾÷ ¼ö¿äÁ¶»ç
>     * ÀüÀÚÁ¶´Þ ⱸ 'G2BÆ÷ÅÐ' À̸ñÁýÁß
>     * Á¤ºÎ¡¤°ø°ø Á¶´Þ¾÷¹« ¿¬³» ¿Â¶óÀÎÈ­
>     * °°Àº ¾÷Á¾ Áß¼Ò¾÷üµé ERP °øµ¿ ±¸Ãà '·¯½Ã'
>     * 'Ŭ¸°º¥Ã³ ÀÎÁõð¤' ÃßÁø
>
> What is the country for this organziation?  Phone number?  How would you
> determine what currency to use in a procurement transaction?
>
> HTML is not acceptable nor is simply making the whole ebXML
> infrastructure rely upon Dun and Bradstreet doing something they have
> informed us they are not interested in doing.

<TW>
Who ever said anything about making the whole ebXML infrastructure rely on
D&B?

Putting aside the hyperbole, nothing at all in the CPPA spec is dependent on
D&B.
</TW>

> To implement this properly,  we just need a few small pieces more.  I
> think you guys are doing a great job and can easily fit in a mechnism
> that can give implementors an intelligible piece of XML to process to
> extract this information.
>
> Best Wishes.
>
> PS - I like the recent changes to CPP/A.  Keep the work rolling ;-)
>
> Duane Nickull
>
> --
> CTO, XML Global Technologies
> ****************************
> Transformation - http://www.xmlglobal.com/prod/foundation/
> ebXML Central - http://www.xmlglobal.com/prod/central/
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>