Re: [ubl-dev] Creating a new document... where to start?

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Maybe I'll reply to my own message here - 

I think it might be sufficient for this matter for small businesses if certain documents
(particularly the order if just a simple order/invoice process is the
case in point) have, besides things like 'AcknowledgementResponseCode'
(which just applies in 1.0 to the type of OrderResponse to follow an order),
some other code like 'ReturnedInvoiceCode' with values like 'SmallBusinessProfile',
'ContextSpecificProfile' (which would require something like the ebXML CPA
to specifiy what that context is and the respective profile - but small businesses
applications might not be able to cope with ebXML/CPA) and another code
for a fullblown vanilla response being acceptable (can't think of a suitable value)

A more general code or identifier or a more specific indicator (like SmallBusinessIndicator)
are alternatives to consider.

Incidentally, in UBL it is generally taken that an Identifier differs from a code in
that a code just has a codelist whereas an identifier can be open or be used
with a pattern (not necessarily incorporated into the vanilla Schemas since more than
one might be used). A pattern to consider for something like the above but
very general might be a combination of codes, one for each 'context driver' in
the ebXML/CEFACT sense, with specified separators like A:B:C:D:E:F:G:H
where an example for small business procurement might be 'Procurement:::::::SmallBusinessProfile'
(the first of the eight drivers being business process and the last being system constraint
- see a UBL 1.0cd model spreadsheet for the others).

There would be pros and cons for each option and the small business app industry might
like a different approach, but I'm minded to see if this can incorporated into UBL 1.1
(via a comment or position paper or e-mail submission)

Incidentally, it is as well to point out that there may be scope for things like this to
be included in 1.1 or later if they are more general than can be catered for in
a specific customization.

I'd not think it appropriate to rely in this case on the small business profile to include
this as an extension since it would mean a new namespace, I think, for the profile
and lack of recognition up front by those using other profiles - the ones the profile
seeks to keep on board. I really see small buisiness inclusion in UBL use being beyond
the realms of customization, but that is probably disputable and controversial in UBL.
After all small business apps may be the main ones which can't readily incorporate
(at an affordable cost price) the CPA/context driver technology (which I gather doesn't
fully exist yet - I may be wrong). A 'selling' point of UBL is that it doesn't require the
use of ebXML/ISO15000 and I'd hope that UBL can be used (with this matter sorted)
in simple e-mailing applications as are available now in certain small business finance
products.

All the best

Stephen Green



>>> "Stephen Green" <stephen_green@seventhproject.co.uk> 23/06/04 05:53:29 >>>
Ken

Mmm..  Thanks for that. But (I'll acknowledge my colleague Paul Johnston's
idea
behind this).. what I need is a way for a SBP-user to say to anyone 'I'd
like pro-SBP
(i.e. SBP-friendly) messages please' e.g. when sending the order - 'Please
return
an SBP-friendly invoice,etc'

With ebXML I guess that could be in the CPA and that gets registered. This
gives
small businesses the means to say 'I want SBP-friendly orders' before any
document
gets sent.

UBL does have an order response code in the order. Maybe it should have a
general response code in every document.

Steve

----- Original Message -----
From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
To: <ubl-dev@lists.oasis-open.org>
Sent: Wednesday, June 23, 2004 1:03 AM
Subject: Re: [ubl-dev] Creating a new document... where to start?


> At 2004-06-22 20:55 +0100, Stephen Green wrote:
> >You expound on 'constraints' and explain that XSD needn't be used
> >to express them,
> >
> >but:-
> >
> >If XSD were to be used;
> >
> >Is there a (standard or accepted) way to say in or with the XSD
> >what *kind of constraint* we are using? (I refer to the kinds of
constraint
> >at the end of your message)
>
> Nope, not that I can think of.
>
> >If not, can we invent one?
>
> Not that would be schema expression independent (so as to allow schema
> expressions in many possible schema expression languages to determine it).
>
> If we had an attribute or element in the instance, we might imply the
> semantic of "standardized full UBL" when that information item is absent,
> or "contextualized UBL" when the information item is present, and then
> publish a mechanism by which we syntactically represent context in the
> information item.
>
> Say it were an attribute ... when absent in the instance, a processing
> application can assume it has the full range of UBL to expect.  When
> present in the instance, it might have values, say "SBP" for the small
> business profile, or "SBP:Auto" for the small business profile used in the
> automotive industry.
>
> Then, we could add the constraint to each profile that the context
> information item be properly formatted for that profile ... then when you
> validate the instance against the profile, rogue values would be flagged,
> and when you validate the instance against full UBL all values would be
> acceptable.
>
> But I'm wary of signalling the context physically in the instance ... but
I
> don't know why I'm uneasy about that.  On the surface it seems to make
> sense: an application can recognize from the context which set of
> supplemental or derivative constraints are needed for validation.  But I
> think the reason goes very deep.
>
> >P.S.  I guess 'context' gives us a way to say the *reason* for the
> >constraint(s)
>
> Yes, but its "messy".  Not only would we have to introduce such an
> information item into UBL 1.1, but I'm wondering if it is somehow breaking
> the arbitrariness of the flexibility of applying different schemas to
> different instances.  Perhaps not ... I am anxious to hear other users'
> comments.
>
> You see, the thing is that an application that is tied to the SBP need
only
> validate that an instance fits the SBP constraints on top of the UBL
> constraints ... of what use is a signal to say "this is an SBP instance"
> when a validation task will tell an application that anyway.
>
> In fact, maybe now I'm thinking it is too limiting to actually tag a UBL
> instance to be an SBP instance ... what if a fully-supported UBL
> application outputs an XML instance that meets the user's needs, and it
> just coincidentally happens to meet the SBP constraints: an SBP
application
> will successfully work with it because it passes the SBP constraints.  If
> it doesn't pass the constraints then it could never have been used.  If
the
> SBP were looking for a signal, and that signal either wasn't there or we
> made the signal a mandatory part of the SBP profile, then the user loses
> out on possible benefits of using the SBP software that they would have
> been able to use had the validation been based solely on the presence of
> UBL information items, not on the value of a magic attribute.  But without
> the explicit signal the instance is simultaneously usable in all of the
> possible UBL contexts to which it validates.
>
> So all that thinking aloud to come to the conclusion that, "no", don't put
> anything into the instance to signal it is an SBP instance .... just let
> validation assess that it is an SBP instance so as to put the burden back
> on the application and the flexibility back in the hands of the
> users.  Whenever they happen to create an instance that passes SBP
> validation, they have the flexibility to use SBP software.  If their
> particular needs one Thursday afternoon requires them to use additional
> properties, then they have those additional properties and SBP software
> rejects the instance, but that's okay because the user should have avoided
> those properties and validated the SBP constraints if it was important
that
> they had to use SBP software.  And, from time to time users may have
> instances that are simultaneously usable in software that supports a
number
> of different profiles, and then they don't have to do anything at all to
> take advantage of all of that software.
>
> ...................... Ken
>
> --
> Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
> World-wide on-site corporate, govt. & user group XML/XSL training.
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com 
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/ 
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc 
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal 
>
>