Re: [ubl] Information items in 2-prd2-cd minimal instances

[Tim McGrath <tmcgrath@portcomm.com.au>]

to some extent this is a bit of a sideshow to the broader customization 
debate so lets not invest too much energy as yet.  however i do repeat 
that document types (such as Waybill) are not broken just because they 
dont have a workable mandatory subset.  creating one (to stifle teckies 
taking shortcuts) doesn't seem like the sensible approach. 

as it happens when trying to create sample instances with XMLSpy i used 
the 'only mandatory elements' option and got documents that looked like 
your reports, then went back and added the "out of band stuff".  this 
proved to me that the out of band stuff is sufficiently different for 
each implementation (and instance) to make it impossible to standardize.

its true it wasn't an exhaustive test but in my mind we are close enough 
to the 80/20 line on this.

G. Ken Holman wrote:

> At 2006-08-14 13:22 +0800, Tim McGrath wrote:
>
>> G. Ken Holman wrote:
>>
>>> At 2006-08-13 10:49 +0800, Tim McGrath wrote:
>>>
>>>> no business rules are used to guide this model and as such it is 
>>>> fairly meaningless.  no-one could use this model as-is.  consider 
>>>> the waybill - it only decribes a shipment and no parties involved!
>>>
>>> Does that mean that it doesn't have sufficient mandatory elements 
>>> for a UBL document type?
>>
>> This is my (and sylvia's) point, there isn't really a minimal set of 
>> mandatory elements that would in their own right constitute a 
>> meaningful (and/or legal) exchange.
>> ...
>> In this situation stating here are my shipment details in isolation, 
>> may be technically valid but not much use.
>> ...
>> OK, I see now your vision of Open-UBL.  This is another part of the 
>> customization puzzle we should consider in the approach we are 
>> defining.  You are proposing a minimal subset (or what i would call a 
>> "core pattern") for each document type. An approach Bob and I refer 
>> to as "Core plus Contextualization" in our [highly acclaimed] book.
>
>
> Actually, I'm trying to state something stronger:  that our choice of 
> the minimal mandatory set of information items in the document type be 
> considered the "core" that conveys at least enough information for 
> parties to continue on "out of band" and complete the transaction.
>
> It could be that the document types are there now ... I wouldn't know 
> so that is why I published what is there right now and asked the 
> question of the committee as a comment in the process ... but if other 
> comments are sufficient to warrant a change in the schemas, it might 
> be worthwhile to review the minimum mandatory elements to see if 
> something can be changed to flesh out the core for some of the 
> document types.
>
>> However i suspect what actually constitutes this "core" or miminal 
>> subset, cannot be automatically derived from our models or schemas. 
>> It seems to me more like another SBS-type project.
>
>
> I'm of the opinion this is a TC decision of minimum mandatory elements 
> because the non-XML'ers out there who use UBL may be (will be?) 
> tempted at times to use the absolute minimum "just to pass the schema 
> validation" without regard for completeness.  Think of the techie who 
> has been told by his boss:  "make this document pass" ... I can easily 
> picture that as soon as he has used enough information items such that 
> there are no schema problems, he will believe that he is done.
>
> While I *totally* agree that users should choose how much of UBL makes 
> sense, choosing an SBS suite of optional elements, or your suggested 
> "core" suite of optional elements, I also believe there will be a 
> class of user out there who believe that they have done "enough" if 
> their instance validates against the document model.
>
> But I do not believe this should delay the release of UBL 2.0 ... if 
> there are no other changes in the comments that trigger a new review, 
> then these comments of mine aren't important enough to do so 
> themselves.  However, if for other reasons there is going to be the 
> need for another review, this would give us a chance to consider the 
> 31 reports of the minimum information items for each document type and 
> make a few more items mandatory so that a minimal instance of each 
> document type isn't missing an obvious piece of information that has 
> been overlooked during development.
>
> That is pretty subjective too ... since I am relying on "out of band" 
> completion of the transaction while using a minimal instance to convey 
> the essentials of the transaction, the out of band stuff would be that 
> that the receiver can deal with (including static details about the 
> sender; after all, I'm assuming they know with whom they are dealing) 
> without missing any transient details specific to just the transaction.
>
> I suppose that would be the distinction:  assuming that I know the 
> sender (because that is why I've engaged this special mode of 
> operation), I can assume the static information that is true about the 
> message across all messages from the sender ... what the minimum 
> information in the instance would be would be that which is specific 
> to the transaction that the receiver cannot assume in order to 
> complete the transaction out of band.
>
> I hope this is considered helpful and not distracting.  It came to 
> mind when I was trying to "just make the dang instance validate" for 
> one of my localized tests, which led me to create the XPath report (so 
> I wouldn't have to look in the XSD schemas), which directed me on how 
> to do so by enumerating the minimum mandatory elements.  I then 
> realized this mindset might not be all that uncommon, having witnessed 
> it in publishing, where technologists might try to take such shortcuts 
> in e-commerce ... they could then blame the UBL TC for not making the 
> mandatory minimum elements sufficiently descriptive to still be 
> actually useful.
>
> While I would like to believe in the ideal that new users of XML are 
> anxious to learn how to do things properly, I've seen otherwise.
>
> . . . . . . . . . . . . . Ken
>
> -- 
> UBL/XML/XSLT/XSL-FO training:         Vårø, Denmark 06-09-25/10-06
> World-wide corporate, govt. & user group UBL, XSL, & XML training.
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath