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] More comments on Tag Structure paper


In case the decision hasn't already been made by the time anyone 
reads this, I think Mark makes a good argument.  However, I don't 
think we're going to be able to get away from keeping track of context 
while trying to understand the data.  It doesn't take much more than 
a few examples to demonstrate this.  Take the case of a ship to location 
which typically might appear as a default in the header of a PO, 
but with an over-ride ship to location on a detail line.  Without 
context, we have to have something like:

headerShipToParty

detailShipToParty

instead of just ShipToParty

This has greater impact the deeper we nest things, and we'll probably 
end up creating uniquely named data elements for each document.

Also, what happens when we have multiple line items, each with their 
own ship to locations?  I realize this is a somewhat different case 
since we are talking about instances of the same thing rather than 
different things, however this demonstrates that context needs to 
be established when dealing with one line item vs. another.

Again, we also lose a lot of the reusability that comes from having 
common , shared types, since each child element in a complex type 
must have a name that is prefixed with the parent object class name.


I think Mark makes a good point, but I think the proper way to make 
this tradeoff is to favor reusability over processing efficiency.


-------------------------------------
Mike Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com




=end of email===




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


Powered by eList eXpress LLC