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

["Stephen Green" <stephen_green@seventhproject.co.uk>]

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
>
>