OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: How to differentiate between a NO-CHANGE and DATA-ITEM-TO-BE-REMOVED in UBL-OrderChange-2.0.xsd


Hi Jeurg

 I view of the scope covered in UBL 2.0 modelling, I would suggest,
 for relatively complex changes, either cancel the order and reissue
 it or when OrderChange is used, make the OrderChange a complete
 rewrite of the Order (essentially an implicit cancel and reissue).

 In the case of the OrderChange there would be merit in using the
 status code to *highlight* the changes where possible. However
 this would be more informative than instructional. The instruction is
 determined by the business process followed but would take the
 line 'the OrderChange cancels and replaces the previously issued
 Order that it references' if my suggestion is followed. The informative
 nature of use of status codes and reliance instead on external
 process definitions and the like for the business instructions seems
 to me to also be in keeping with the absense of the status code
 from some UBL documents.

 This is just a suggestion and not something I have personally even
 had practice implementing so anything which isn't explictly covered by
 the UBL spec would be up to implementers and business architects
 to apply as separate from UBL compliance as such. My suggestion is
 just one approach you might explore but with hindsight of what was
 envisaged in the design stages of UBL (more to do with UBL 1.0 than
 2.0, from my experience). * Please don't sue me if my suggestion does
 not meet your requirements * :-)

 All the best

 Steve




 On 14/04/2008, Juerg Tschumperlin <Juerg.Tschumperlin@minedu.govt.nz> wrote:
 > Hi,
 >
 >
 >
 >  How should one populate an instance document based on
UBL-OrderChange-2.0.xsd
 >  in the following scenario:
 >
 >
 >
 >  -          The original UBL-Order-2.0 instance contained several OrderLines.
 >
 >  -          One of these OrderLines had 3 BuyerProposedLineItems
 >
 >  -          Later on, an update occurs to the order, resulting in a instance
 >  document based on UBL-OrderChange-2.0.xsd: The second BuyerProposedLineItem
 >  is to be removed
 >
 >  -          How would one differentiate between NO-CHANGE and
 >  DATA-ITEM-TO-BE-REMOVED? Should I use the OrderLineStatusCode to indicate
 >  this unambigously?
 >
 >
 >
 >
 >
 >  -          In other cases however, such as
 >  UBL-CatalogueItemSpecificationUpdate-2.0.xsd, there is no such a status if I
 >  wanted to remove one of the many Notes.
 >
 >
 >
 >  Obviously, the issue arises whenever an instance is meant to update
 >  previously transmitted data.
 >
 >
 >
 >
 >
 >  In short, for UPDATING instance documents, how do I differentiate between
 >  NO-CHANGE and DATA-ITEM-TO-BE-REMOVED? Populate all necessary data items,
 >  including UNCHANGED ones? That would mean that absent (occurrences of) tags
 >  could mean a DELETE if data values for them were specified previously. I
 >  would think however that this is in conflict with UBL NDR rule [IND6] The
 >  absence of a construct or data in a UBL instance document MUST NOT carry
 >  meaning.
 >
 >
 >
 >  Your thoughts on this are much appreciated.
 >
 >
 >
 >  Regards
 >
 >
 >
 >  Juerg Tschumperlin
 >
 >  Wellington, New Zealand
 >
 >
 >
 >
 >
 >
 >
 >  DISCLAIMER
 >  This e-mail is intended for the addressee only and may contain
information which is subject to legal privilege. The contents are not
necessarily the official view or communication of the Ministry of
Education. If you are not the intended recipient you must not use,
disclose, copy or distribute this e-mail or any information in, or
attached to it. If you have received this e-mail in error, please
contact the sender immediately or return the original message to the
Ministry by e-mail, and destroy any copies. The Ministry does not
accept any liability for changes made to this e-mail or attachments
after sending.
 >  All e-mails have been scanned for viruses and content by security
software. The Ministry reserves the right to monitor all e-mail
communications through its network.
 >
 >



-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606
Associate Director
Document Engineering Services
http://www.documentengineeringservices.com

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]