Thanks for keeping us honest and provided a valuable sanity check.
At this stage we want to avoid making changes to schemas that would
require implementators using PRD2 schemas to change their applications.
This is what OASIS classifiy as a significant change and as such would
require a third public review. We will only do this is the schemas in
PRD2 are actually broken (not implementable). This means most content
changes will be deferred to the next release.
The imminent second public review is only an opportunity for the public
to comment on changes between PRD1 and PRD2. New issues will roll into
post UBL 2.0. Of these, issues which do not break backward
compatibility will be candidates for UBL 2.1, issues which break
backward comatibility will be candidates for discussion in our
collaboration with UN/CEFACT.
As to where to submit comments, the UBL TC list is fine (or the PSC list
if you are a member). As a member of the UBL-TBG1 collaboration team
you also have the opportunity to express your views in that forum.
So keep them coming!
I have specific responses to your first issue in-line below...
Stephen Green wrote:
>Hi UBL
>
>I'm not sure to whom I should post this or other similar
>comments; to UBL, to PSC, to Comments or even to TBG1.
>
>I've been looking some more at the SBS and mapping it
>between UBL 1.0 SBS and UBL 2 and am coming across many
>questionable issues such as the following so I'd kind of
>regard these as potential comments from inside the TC
>so how would such be handled. Will there be any scope
>to revise UBL 2 at all or are all changes suggestions
>to be carried forward to the TBG equivalent(s) of 'UBL 3'?
>
>Here is my issue for procurement:
>OrderLine - there is now just the one OrderLine ASBIE for
>the Order document, OrderResponse and Order Change. This
>presents a particular challenge for subsets of course but
>that's beside the point. The point is it doesn't have an
>ID (neither did it have one in UBL 1.0) and I wonder how
>accurate or otherwise this makes the OrderLineReferences
>if they are refering to an OrderLine which doesn't have
>an ID, presumably by actually referencing the LineItem
>which does have an ID. The LineItem is not the same since
>there could be for one OrderLine both LineItem and some
>kind of SubstituteLineItem so there is a loss of both
>accuracy and precision when refering to an OrderLine by
>referencing the respective LineItem. This is complicated
>even more if LineItem is virtually empty and something
>like even to QuotationLineReference is used for the data.
>Admittedly the LineItem is mandatory as is its ID, so at
>least there must always be a LineItem/ID for every
>OrderLine. Just that there are other ID's that might be being
>used instead or as well - a headache perhaps for implementers.
>
>
>
As you point out, an OrderLine must have one (and only one) LineItem and
this LineItem must have one (and only one) ID, the ID of the LineItem is
effectively the same as the ID of the OrderLine. The reason we use
OrderLineReference is so that you are able to identify any other
LineReferences (such as Catalogue) and DocumentReferences. Remember
that although an OrderLine may have one (and only one) LineItem, a
LineItem does not know which OrderLine refers to it and some LineItems
are not from Orders.
I suspect the fact other IDs (such as
BuyerProposedSubstituteLineItem/ID) may be used as well is not
problematic. Yes, it could be the same value as the LineItem/ID but it
is put there to provide for when it differs. Common sense would suggest
you wouldn't repeat it.
If you are suggesting we need an ID for OrderLine then this wouldn't
this make matters worse?
>I've a good few further issues to come so I'd appreciate
>a ruling on how to submit them as a TC member.
>
>All the best
>
>Stephen Green
>
>
>
--
regards
tim mcgrath
phone: +618 93352228
postal: po box 1289 fremantle western australia 6160
web: http://www.portcomm.com.au/tmcgrath
