ubl-ndrsc — archive

Re: [ubl-ndrsc] Containers?

From: Tim McGrath
To: [email protected]
Date: Thu, 11 Sep 2003 01:39:00 -0000

 MHonArc v2.5.0b2 -->

ubl-ndrsc message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]

Subject: Re: [ubl-ndrsc] Containers?

From: Tim McGrath <[email protected]>
To: Danny Vint <[email protected]>
Date: Thu, 11 Sep 2003 09:59:54 +0800

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
> [email protected]                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

Follow-Ups:

Re: [ubl-ndrsc] Containers?
From: Dan Vint <[email protected]>

References:

Containers?
From: Danny Vint <[email protected]>

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]