[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] Containers?
thanks Dan for encapsulating the overall concepts involved in this debate. i think you have described a common view and are correct in claiming this is not an XML issue, but a conceptual design one. my take on these points is: a. the containers we have currently adopted are based on normalising the business entities and their attributes into ABIEs, BBIEs and ASBIEs. this creates a conceptual model that can be expressed in XML or any other data representation language including database schemas. to create 'documents' from these we create hierarchical paths joining the ABIEs togethers, based on the context of the document in question. for example, an Invoice mights view a relationship as Line-Item-Package and a Delivery Docket as Line-Package-Item. thats the way it has been done for 5000 years and we are not going to change this. following this approach gives us nested hierarahcies of containers based on recognised associations. i don't think we have had too many arguments that this delivers useful models and resultant schemas. - which leads to my next point: b. some documents (emphasise the 'some') have a structural pattern. you cite the example of Order=Header+LineItem(s) {sometimes people like + Summary as well}. i agree these are patterns but what value does formally identifying these give us? they are not terribly re-usable because they are containers for one specific type of document. for example, an OrderLine cannot be re-used as an InvoiceLine. they are not universal patterns. in some ways it is unfortunate that UBL chose the procurement business context for its initial library. the Header-Line(s)-Summary is replaced by Header-Good(s)-TransportEquipment(s) -Summary or just Header on its own or just TransportEquipment(s) in things like Transport documents. once we move away from provurement, it soon gets very messy. So we come to a situation where we would have difficulty formalising an approach to identify these structures (outside their already known business associations) and the results would not gain more re-usability. i have given a fair amount of thought as to why these structures are appealling on first examination. the two answers i can come up with are that 'this is how the printed documents always look' or 'it helps with containership processing'. not surprisingly, these are related factors. however, i think the former has little bearing on e-business electronic documents and the latter (which i understand is an XML issue) seems to be debatable. I think the situation we now have is that we favour not committing to an approach we are unsure is necessary. If i cast your example in pseudo-UBL it would look like this... <PurchaseOrder aka Order> Date Purchaser Shipping Address etc <Order aka OrderLine>* <Item> sku color qty ordered part number desc price </item> </Order aka OrderLine> </PurcahseOrder aka Order> - are we really missing anything here? Danny Vint wrote: > Just got to thinking about the line items and the head issue/rules. I > don't want to prolong the discussion but like several folks I'm a > proponent of containers, but maybe not "generated" containers. It > appears that ABIEs are containers that the business folks somehow deem > important/worthy of being business objects. > > In John's email he mentioned the Line Items were not in a container > and on today's call the indication was that the rules for having a > "head" group separate from the "body" group was also going to be removed. > > Don't other people see an "order" being composed of something like this? > > <PurchaseOrder> > <OrderDetails> > Date > Purchaser > Shipping Address > etc > </OrderDetails> > <Order> > <Item> * > sku > color > qty ordered > part number > desc > price > </item> > </Order> > </PurcahseOrder> > > Now I've written these as XML, but aren't these general concepts that > you would talk about and work with normally? Those look like some of > the containers we were trying to generate Head => OrderDetails and > Container => Order. > > I haven't looked at the details but maybe someone is being to "strict" > on the business data/library side and there are some more natural > objects that would satisfy some of our qualms/feelings that something > is wrong and still allow the Library folks to work with business data > and not worry about XML details. In this case it isn't just an XML > concern it feels like something is missing anyway. > > ..dan > ------------------------------------------------------- > Danny Vint > ACORD ACORD > 2 Blue Hill Plaza - 3rd Floor > dvint@acord.org Pearl River, NY 10965 > http://www.acord.org > > Voice:510:522-4703 HQ Phone: 845.620.1700 > FAX: 801-749-3229 > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php. > > -- regards tim mcgrath phone: +618 93352228 postal: po box 1289 fremantle western australia 6160
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]