Re: [ubl-ndrsc] Containers?

[Dan Vint <dvint@acord.org>]

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

Does it have to be reusable? Maybe that is the hangup.


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

And is there something wrong with that?



>I think the situation we now have is that we favour not committing to an 
>approach we are unsure is necessary.

I agree on the "auto-generated" containers being problematic, but not the 
introduction of containers directly in the spreadsheet.


>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?

Did you mean your Order to repeat and not the internal Item? I would ask 
what the purpose of the completely useless step between Order and Item is 
used for and even why it is there if this is correct. That is a "container" 
that I can't come up with a need for. The Order is all the items that it 
contains, there aren't multiple orders.

I'm a little less worried about the head=>Order Details idea, so in this 
example I would just change where the repetition occurs and I would be much 
happier. If  your repetition factor is in the right place then I really 
wonder what we are doing and what you see the <Order> element providing.

..dan


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