Re: [ebxml-cppa] CPPA Version 1.05

[Duane Nickull <duane@xmlglobal.com>]

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.  

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

> 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?  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".  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.

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/