RE: [ubl-ndrsc] R13 contradiction

["Stuhec, Gunther" <gunther.stuhec@sap.com>]

Hello Eve,

that's correct, if some BIEs bound on the exactly the same type, the global declared element could be the same. But what's happen, if one of that BIEs is different? I guess, we have to change the type and the tag name. And what kind naming rule do we using for this additional type and global declared element?

The modification of BIEs will be not happen during the design phase only. There can be some modifications during the run time, too. That means, that we have to change all the application interface, too. Because a changing of tag names will impacting all interfaces, too.

For example I have two aggregates: SellersAddress and BuyersAddress and this aggregates have the same subelements: ID, Surname, Givenname etc. This subelements based on the same types, therefore we can use the same global declared elements for it. 

But what happens, if I would like to restrict the ID within SellerAddress and Surname within BuyerAddress after a while. I have to generate to new global declared elements, like "SellersAddressID" and "BuyersAddressSurname". I will get some further problems. I have to change all tag names within my different interfaces and programs, too. Even when I have not recognize this changes within my programs and interfaces.

Kind regards,
	
	Gunther

-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com] 
Sent: Samstag, 18. Januar 2003 01:08
To: Tim McGrath
Cc: ubl-ndrsc@lists.oasis-open.org
Subject: Re: [ubl-ndrsc] R13 contradiction


I'm sorry, I didn't mean to denigrate anyone/anything by referring to 
nightmares!  I had assumed that it was a perl script feature amusingly 
and trivially out of control.

If all the identifier-related elements have different types, then under 
the global-element regime they must indeed be declared as different 
elements with different names (name="{something}ID") and be referred to 
with ref="{something}ID".  But if they all are able to be bound to the 
exact same type, then there is no reason to have different unique 
elements; the parental context of each is enough to distinguish its 
unique semantics.  I had thought the script was gratuitously keeping 
{somethings} where none were needed....

So, wherever the current spreadsheet has instances of multiple elements 
with the same name but different types, then the cleanest way to put 
things back into a consistent state is to change the spreadsheet 
content.  (Trying to have a script do the job won't work, because there 
are semantic decisions to be made here.)  But I had thought that Bill's 
tester script found only a few cases of this.  I wouldn't expect 
wholesale spreadsheet changes to be made hastily at this point over this 
issue.

(I suspect that when we get the full code list solution working, since 
identifiers are now first cousins to codes many of them will want to be 
uniquely typed, so IDs will eventually have this problem even if they 
don't today.)

I'm really sorry that I don't have more time to spend on this right now 
than some email moments here and there...  I'm in favor of global 
elements, but I'm also in favor of doing the right thing by the schedule 
and the expectations of reviewers.  Hopefully these thoughts will help.

	Eve

Tim McGrath wrote:
> Let me correct what i think is a misconception that has led to a 
> spurious debate.
> 
> The problem the LC had with the documentation is not a 'bug' - it has 
> nothing to do with the perl-script generation of schemas. 
> it is a logical problem.  If we want to gloablly refernce things called 
> "ID"  when we have many different uses of "ID" - we have to have a way 
> of saying which "ID" we are talking about.  if we had a schema that said 
> "ref=ID"  is it Party.ID or Transport Equipment Seal.ID ??
> 
> How else but by saying "Ref=PartyID" or "ref=TransportEquipmentSealID"? 
> Dont caste off this as a perl-script bug - it is a side-effect of the 
> global referencing rule.
> 
> If it is a freakish nightmare - show us what it should be.

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>