RE: [Fwd: RE: on the issue of PartyId]

[Scott Hinkelman/Austin/IBM <srh@us.ibm.com>]

All,
I agree we have decended into physical representation wars, as there are
many
ways to indicate the same semantics in XML, and more issues have emerged
but at the incorrect level (physical) IMHO. Backing up and keeping at a
logical
discussion, I think we need agreement that ebXML willl specifying the
Partyid value
as a URI default, and the ability for the upper level software to specify
both the
Partyid value and it's context/domain/type value alternately from the
default.

I am sensing from the conversation that we have established agreement at
this level,
which is my main concern. Is this true?

Scott Hinkelman
Senior Software Engineer, IBM Austin
Emerging Technologies, SWG
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074



"Burdett, David" <david.burdett@commerceone.com> on 09/22/2000 04:44:59 PM

To:   "'David RR Webber'" <Gnosis_@compuserve.com>, Scott
      Hinkelman/Austin/IBM@IBMUS
cc:   ebxml transport <ebxml-transport@lists.ebxml.org>, "'Henry Lowe'"
      <hlowe@omg.org>
Subject:  RE: [Fwd: RE: on the issue of PartyId]



>>> ebXMLpartyID ( URIpartyID | partyIDref | partyIDcode )   <<<

... I think we're descending into an XML style war here ... this and my
suggestion could both work (as no doubt could others) as they are
semantically the same ... and I'm not sure that a vote by the TRP group
would solve the problem as it could still result in inconsistent approaches
within the same spec ... perhaps the TRP editor should ensure consistency
(grin) ... HELP !!

David

-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Friday, September 22, 2000 2:04 PM
To: Scott Hinkelman/Austin/IBM
Cc: Burdett, David; ebxml transport; 'Henry Lowe'
Subject: RE: [Fwd: RE: on the issue of PartyId]


Message text written by Scott Hinkelman/Austin/IBM
>since the FIXED
by definition indicates
the behaviour of the "XML Processor"  (meaning standard validating parsing
routines
and an additional application validation logic) is to act like it was
present with
the default value if not there. Otherwise we may have to say more.

I'm getting way too Picky on this. <

>>>>>>>>>>>>>>>>

Picky or not the parser sure will be picky if it is FIXED attribute - it
will
not allow anything else!    The DTD has to be a little more flexible to
get the behaviour set.  I'll fiddle with it over the weekend some.  DTD's
really are a messedupmucxed up beast - hard to believe that the
W3C let them out the door in the state they did <g>.

Thinking a compound block with  two optional elements, with
different attributes is the way to go - that way the varient you
pick determines the style you are using -

 ebXMLpartyID ( URIpartyID | partyIDref | partyIDcode )

sort of thing.....

DW.