Re: [ubl-dev] Order element for enquiries

[stephen.green@systml.co.uk]

Hi Michael

I'm not sure whether this is wisdom but it's sort of consensus at
any rate:

As a general rule #1, use the most specific element, which in this
case would be cac:SellerContact/cbc:Telefax

However, to improve on rule #1, there's a well agreed strategy for
this kind of thing which is to use subsetting (subset customising
with UBL schema conformance, i.e. still validate against standard
UBL schema) to remove as much as possible optional elements which
in your scenario would cause this kind of duplication.
So rule #2, there should be as close to possible only one place in
the instance to put the data - and subsetting is one way to
engineer that.

Another way to get to rule #2 is to provide an implementation
guide - a set of rules to tell users where to put their data :-)
But essentially that is almost the same as subsetting, and it
has pros and cons compared with subsetting.

e.g.  suggested pro for user guide: can still use
/ord:Order/cac:SellerSupplierParty/cac:Party/cac:Contact/cbc:Telefax
when appropriate (guide defines what is appropriate)
suggested con for user guide: maybe cannot validate against use of
/ord:Order/cac:SellerSupplierParty/cac:Party/cac:Contact/cbc:Telefax
when inappropriate (unless there is a clever way invented to use
something like artificial intelligence to 'understand' content)

A typical full scale implementation guide might use both approaches.

Some actually forbid use of certain elements, e.g. you could forbid
use of /ord:Order/cac:SellerSupplierParty/cac:SellerContact/cbc:Telefax
by creating a conformant set of schemas without it present and say
validation is performed first against UBL standard schemas (for
sake of conformance to UBL) and secondly against your custom schemas
which don't have
/ord:Order/cac:SellerSupplierParty/cac:SellerContact/cbc:Telefax
and both have to pass. This rule would then be applied before
*sending* the message (be strict on sending, lax on receiving -
Postles law).

Personally I would prefer it if I could just make an amendment to
say that my software would accept the
/ord:Order/cac:SellerSupplierParty/cac:SellerContact/cbc:Telefax
but that it might not process it but there seems to be a problem
enforcing the rule if that is added (how would the rule be tested
with that caveat included???) - so how would it be specified?
Leaving /ord:Order/cac:SellerSupplierParty/cac:SellerContact/cbc:Telefax
in the implementation guide would mean a rule for the sender needs
to be stated about when to use it.

In a shorter (sorry) answer to your question, UBL would have
considered any hard and fast rules about this to constitute an
actual implementation guide and the nearest we got to writing
it was the UBL SBS which didn't reach completion for UBL 2.0,
only for UBL 1.0. Really, for UBL 2.0 the options are to write
your own or use a third party one (like NES or OIOUBL). Or if
you want you could even use mine and adapt it - it is called
SystML2 and the schemas for it are on sourceforge
http://xforms4ubl.svn.sourceforge.net/viewvc/*checkout*/xforms4ubl/Schemata/SystML2/SystML2.zip?revision=42
so adapting them within the GPL terms is perfectly acceptable.
However you might find they are suitable as they are (they
do, as far as I can tell by a quick check, exclude
/ord:Order/cac:SellerSupplierParty/cac:SellerContact
and therefore recommend or require, depending how you implement
them, senders to use just
/ord:Order/cac:SellerSupplierParty/cac:Party/cac:Contact/cbc:Telefax
for everything

(I could, of course, have excluded
/ord:Order/cac:SellerSupplierParty/cac:Party/cac:Contact/cbc:Telefax
instead but that would produce a problem if the contact isn't
that of the seller.)

This subset was based on the UBL 2.0 SBS as far as it got (with
some tweaks).

It comes with some nice XForms (see  
https://sourceforge.net/projects/xforms4ubl/ )
which comply with the SystML2 subset.

Of course, if you only use UBL internally, all this could be
academic anyway, but this is how it's done for multiparty or maybe
even community or open mesh implementations.

Best regards

-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606

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



Quoting Michael Strasser <Michael.Strasser@brisbane.qld.gov.au>:

> I have found a pattern relevant to my question. I realised that I
> had forgotten to include the destination fax number in the document!
>
> I was then faced with the analgous choice. Which of these do I use?
>
> /ord:Order/cac:SellerSupplierParty/cac:Party/cac:Contact/cbc:Telefax
> /ord:Order/cac:SellerSupplierParty/cac:SellerContact/cbc:Telefax
>
> Again, any wisdom is appreciated.
>
>
> Regards
>
> Michael
>
>
>>>> "Michael Strasser" <Michael.Strasser@brisbane.qld.gov.au>   
>>>> 7/02/2008 10:03:55 >>>
> I am modelling our purchase order using UBL-Order-2.0 as discussed
> before. Our printed orders display a "For Enquiries Refer To" field
> with the name and phone number.
>
> It is not clear to me which of these components is more appropriate
> in this case:
>
> /ord:Order/cac:BuyerCustomerParty/cac:BuyerContact
> /ord:Order/cac:BuyerCustomerParty/cac:Party/cac:Contact/
>
> My hunch is that the associated Party may be a 'reusable' entity
> with a regular contact (Party/Contact). An order may have a specific
> contact who is different to the regular one (BuyerContact).
>
> I haven't found documentation for UBL that explains this kind of
> detailed semantic distinction.
>
> Does anyone have any wisdom on this?
>
>
> Thanks in advance
>
> Michael Strasser
> Brisbane, Australia
>
>
>
>
> **********************************************************************
>    This message has passed through an insecure network.
>     Please direct all enquiries to the message author.
> **********************************************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>