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

[Dick Brooks <dick@8760.com>]

I believe it's more efficient to use a "context" attribute as opposed to a
URI within the "content" of the PartyId. Attributes are parsed automatically
by the XML parser without any extra effort by a programmer.  A programmer
can access the context attribute information directly via the DOM API, no
parsing needed. If URI's are used the programmer will be required to parse
out the PartyId content into its components, essentially requiring the
programmer to write or incorporate a URI parser. Granted this isn't a big
deal, however it is more vulnerable to bugs than simply placing/retrieving a
value in the context attribute.

I prefer to let the XML parser do the parsing work whenever possible.

Just my .02

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Friday, September 22, 2000 4:45 PM
> To: 'David RR Webber'; Scott Hinkelman/Austin/IBM
> Cc: ebxml transport; 'Henry Lowe'
> Subject: RE: [Fwd: RE: on the issue of PartyId]
>
>
> List-Unsubscribe:
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=unsubscribe>
> List-Archive: <http://lists.ebxml.org/archives/ebxml-transport>
> List-Help: <http://lists.ebxml.org/doc/email-manage.html>,
>  <mailto:ebxml-transport-request@lists.ebxml.org?body=help>
>
> >>> 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.