OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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 

(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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC