[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