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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-psc message

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


Subject: Re: [ubl-psc] New issues from Northern European Subset group


I fully agree too - the advantage is that subsetting is less likely to
remove such an attribute (not good if it can cater for subset
metadata too :-)
 
Can we get an NDR change request in as soon as possible - while
Mavis and Mike are still a bit in editing mode? If there is no objection
from anyone in PSC, I move that it be passed asap to ubl list and
brought up Wednesday.
 
All the best
 
Steve

 
On 20/03/06, Martin Forsberg <martin.forsberg@amnis.se> wrote:
Peter,

I fully agree with this! An attribute is a better solution.

/Martin

-----Original Message-----
From: Peter Borresen [mailto:PLB@itst.dk]
Sent: den 20 mars 2006 13:40
To: ubl-psc@lists.oasis-open.org
Subject: SV: [ubl-psc] New issues from Northern European Subset group

Hi Stephen

Having a Document Context ABIE is a usefull solution, but acording to a
desition made by the TC the version number sould be an Attribute on each
document. If so then the other context identifies should also be
attributes
on the documents. An advatages of having it as attributes is that you do
not
actually have read the document for specifyings its context.

The reason why context is needed in the document is:

1) Document exchange should be posible without introducing agreent
between
the parties.
2) For debugging purpose is it of great value.
3) The document context can be used by the receiver to see witch format
to
send back to.

Kind regards

Peter

-----Oprindelig meddelelse-----
Fra: Stephen Green [mailto:stephengreenubl@gmail.com]
Sendt: 12. marts 2006 19:29
Til: ubl-psc@lists.oasis-open.org
Emne: Re: [ubl-psc] New issues from Northern European Subset group


The answer might seem to be the have the Document Context Identifier as
one of several BBIEs in a Document Context ABIE and have another BBIE
for required response subset or the like (as I requested in UBL 1.0) -
like
the required order response BBIE in Order, etc - but this only works
when the
subset is required in a responding document and doesn't help with a
request
or notification document in which the subset is required.
Thus it makes sense to define all this in the trading partner
agreement (TPA) and/or
ebXML CPP/CPA (or equivalent, if there is one). I guess the same might
apply
to
Martin's suggestion - that it is best deferred to the TPA, etc.
For routing purposes there is the possibility for Martin's suggestion of
putting
metadats to this effect outside of the document somewhere (manifest or
indirect
metadata attached to message id, service id or the like) as well, but
I'm not
so sure having it in the document is the right place (as was suggested
in response
to my 1.0 issue). The danger is that if the right place is in the
message 'header'
or 'envelope' but more especially in the trading partner agreement
(being applicable
prior to sending a message rather than to during processing to ensure
the
right
format is used by the sender so that the receiver can understand it),
then putting
it in the document too is unpragmatic duplication. If I say to you
that I am speaking
to you in Welsh but you only speak English, how ill you understand me to
know
what I said. Better to agree in advance to speak what I can understand.

All the best

Steve



On 12/03/06, Stephen Green <stephengreenubl@gmail.com > wrote:
> Correction in the attached
> line 3: 'the sender may wish to signal somehow to the sender'
> should read 'the sender may wish to signal somehow to the receiver'
>
> On 12/03/06, Stephen Green < stephengreenubl@gmail.com> wrote:
> > Just to mention that with the SBS subset design, the subset document
is
actually
> > an ordinary UBL document, with the same UBL namespace so these
issues
don't
> > apply. The issue related to these that does apply is that the sender
may
wish to
> > signal somehow to the sender that they need the responding document
to be
> > compliant with the subset (though it would nonetheless be a vanilla
UBL
document
> > all the same). Essentially the naespace is plain old UBL so another
mechanism
> > is required for the SBS other than that suggested. The emphasis is
not on
the
> > document being semt but on the subset used for the document to be
received.
> > It may be, importantly, that the document received, which has to be
subsetted
> > to be properly understood (by machine), is not the response to a
previously sent
> > document ( e.g. it might be a notification process document such as
invoice) so
> > this entails another mechanism such as ebXML.
> >
> > All the best
> >
> > Steve
> >
> > On 11/03/06, Martin Forsberg < martin.forsberg@amnis.se> wrote:
> > >
> > >
> > > There is definitely something wrong with the comment-page. I
received a
> > > strange error message a couple of hours after posting an issue. I
re-post it
> > > here and perhaps Betty can file it in the appropriate list.
> > >
> > >
> > >
> > > After looking at Peters issue list I see that my post is partly
covered
by
> > > one of Peter's. Perhaps my suggestion and description can give
some
further
> > > information.
> > >
> > >
> > >
> > >
> > >
> > > *******************************************************
> > >
> > > Name: Martin Forsberg
> > > Organization: On behalf of Northern European Subset Group
> > > Regarding Specification: UBL2.0
> > >
> > > In the ongoing work within the Northern European Subset group on
> > > e-procurement an issue has come up that we need to find a solution
for.
We
> > > are developing and defining a subset for a couple of common
business
> > > processes and business rules. The problem, in a nutshell, is that
we
can't,
> > > by just looking at a document instance, see what business
process/context
> > > the instance belongs to. We need to identify the context by
looking at
the
> > > instance to decide what business rules (schematron), subset schema
and
> > > optionally what work flow to apply. The Small Business Subset SC
has
> > > developed a great method of defining context specific subsets, but
the
> > > document instance (e.g. the invoice) doesn't reflect it.
> > >
> > > Suggested solutions:
> > >
> > > A new BIE called "Document Context Identifier" of type Identifier
is
added
> > > on document level (0..1).
> > >
> > > By adopting the UN/CEFACT context drivers or other suitable keys,
an
> > > Identifier can be built.
> > >
> > > Example:
> > > For the Order to Invoice process defined in the northern European
subset,
> > > the identifier could be: NES:OrderToInvoice (Geo political context
+
> > > Business process context)
> > >
> > > Without this BIE, the only solution (as we see it) is to define
specific
> > > namespaces for every business process and that will give a very
negative
> > > impact on interoperability.
> > >
> > > Best Regards
> > > Martin Forsberg
> > > SFTI (Single Face To Industry, Sweden)
> >
>



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