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

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

This is very similar in that common sense, it seems to me, dictates
that an order needn't and shouldn't (for legal and business reasons)
have a different namespace just because it obeys a secondary
masking / overlayed / extra requirements / tighter Schema to limit
the possible currency codes used.

It is clear that the codelist mechanism of UBL 1.0 points to the
possibility being provided for in the Schemas to limit the
possible values in the currency codelist used to say just USD. But
does the provision UBL makes in 1.0 require a new set of Schemas
with a new set of namespaces. If so we'd rather, as I feel common
sense dictates, *not* specify any other Schemas but just say that
we'd like to limit our trading partners to just using USD, say.

My question then is, How do we best state our extra requirements
without changing the namespaces in exchanged documents?

Stephen Green


----- Original Message -----
From: "Jeffrey P. Silverstone" <jps-oasis@margreta.com>
To: <ubl-dev@lists.oasis-open.org>
Sent: Saturday, June 19, 2004 5:36 PM
Subject: Re: [ubl-dev] Creating a new document... where to start?


>
>
> I am interested in the same thing, but, perhaps, for a different reason.
> I am looking at writing a front end for an already existing order and
> distribution system. The existing system, for example, only handles US$,
so
> my front end can only take US$. I want a schema to advertise to purchasers
>  that I only take US$ and that I can use to validate that orders are ones
>  that the existing system can handle. On the other hand, I do not want to
>  extend UBL in any way so that every order that I accept will be a valid
UBL
>  order, but not every UBL order will be acceptable to me.
>
> Perhaps I should publish my restricted schema under my own namespace with
no
>  reference to the UBL namespace and then accept the UBL namespaces on
input
>  in addition to my own. Regardless on which namespace, I would have to
>  validate it against my own.
>
>  -- Jeffrey
>
>  ----- Original Message -----
>  From: "Stephen Green" <stephen_green@seventhproject.co.uk>
> To: <ubl-dev@lists.oasis-open.org>
> Sent: Friday, June 18, 2004 3:19 PM
> Subject: Re: [ubl-dev] Creating a new document... where to start?
>
>
> >> Steven and all ubl-dev folk,
> >>
> >>
> >> I'm actually trying to find a clear path in this area too.
> >>
> >> I've been trying to 'customize' the reusable ABIEs
> >> using the 'customization methodology' (as described in
> >> the paper in the UBL package by Eduardo Gutentag
> >> and Arofan Gregory et al) so as to define Schemas for
> >> simpler documents of order and invoice which would
> >> also be valid documents by the original order and invoice
> >> Schemas.
> >>
> >> I end up with, say, an order looking like the first Schema
> >> at the end of this message and the Common Aggregate
> >> Components Schema like that at the bottom below.
> >>
> >> Notice that there are many BBIEs and ASBIEs in the common
> >> Schema with *both* min occurs and max occurs equal to zero
> >> e.g. <xsd:element ref="cbc:District" minOccurs="0" maxOccurs="0">
> >> and that I've imported the original Common Aggregates Schema
> >> and given my schema a new version number.
> >>
> >> I'm not sure about the version number, whether in fact I should
> >> have actually given the new Schema a new namespace. The
> >> 'customization methodology' paper seems to 'outlaw' (as far
> >> as UBL conformance is concerned) the use of the same namespace
> >> in that it points to the NDR rule against the use of redefine in
> >> UBL Schemas so as to force folk to change the namespace.
> >> However, I'm hoping, I guess, that the situation I'm trying to
> >> cater for warrants exclusion from this rule for the sake of producing
> >> Schemas with a different role. Debatable I suppose.
> >>
> >> So this I'd like to discuss at some point: - whether I can get away
> >> with using the same namespace so that the instances created
> >> as valid by the new Schema are exactly the same as if they'd been
> >> created to validate against the original. I hope you'll see more
> >> on this later (e.g. a 'strawman').
> >>
> >> For now, leaving aside technicalities like that, what I'd like
> >> to concentrate on is what goes into my new Schema and what is left
> >> out. (It won't be so trivial as to fit in one e-mail.) For the
> >> requirements I'm concerned with it matters that nothing new is added
> >> so that a new invoice is valid as an old one too. But things are taken
> >> away - and this has problems associated with it.
> >> I obviously want to leave behind anything that used to be mandatory
> >> and leave it mandatory (as per customization paper) but I need
> >> to leave anything intact that other documents I intend to build will
> >> need in an ABIE too. I don't want to have more
> >> than one version of the same ABIE or that would require giving one
> >> of them an new name, which I'm not sure I want. Is that right?
> >> If I took too much out of an ABIE (making it 0..0 cardinality), I'd run
> >> the risk that I might have to create another version of that same ABIE
> >> so that it could be used, perhaps, in another document or another place
> >> in a document  and for that I'd have to have one of the two versions
> >> at least called by another name for uniqueness. That I don't want here.
> >>
> >> ****
> >> I don't want my new instances to be rejected by the original Schemas
> >> but to look to all intents and purposes as if they are just instances
> >> for the original Schemas - to a potential receiving application and
> >> to an auditor or he like at least.
> >> ****
> >>
> >> What I actually want, and I'd value input into this (as much as
> >> can be mustered) is an order and an invoice which are valid
> >> as proper 'vanilla' (original) UBL according to the original
> >> Schemas, but which are (also) defined by restricted,
> >> secondary Schemas to the extent that small business financial
> >> applications can cope with them properly.
> >>
> >> Perhaps someone out there is allowed to share what such
> >> restrictions for small businesses might be.
> >>
> >> One idea I have is to look at a paper from a major accounting
> >> company about what constitutes a minimal or optimal
> >> electronic invoice, then derive a respective order requirement
> >> from that. Any ideas?
> >>
> >> The next step is to work out a way to model the new document
> >> and then a way to generate the Schemas (even by hand if
> >> necessary, but a tool might eliminate errors better).
> >>
> >> I have a few ideas in this direction which I'll hold on to till later
> >> but UBL used spreadsheets to start with for modelling. then
> >> adapted to tool features as neccessary. For now, a starting
> >> point I'd like to try is to add an extra column to the UBL spreadsheet
> >> just after the 'cardinality' column and call it 'new cardinality'
> >> since for what I'd like to do I'm only wishing to restrict the
> >> existing reusable ABIEs. I don't wish to rename anything.
> >>
> >> My document models could, perhaps, be new
> >> without restriction, using these adapted ABIEs but otherwise could be
> >> restricted versions of the originals - I'd prefer the latter. What
> >> do others think?
> >>
> >> Sorry for such a long e-mail. I'd intended to bring up this issue
> >> of restricted Schemas as a proposal for a set of small business
> >> profiles to lower the barrier to entry for use of UBL in small
> >> business finance applications but I couldn't resist using the issue
> >> to answer the question. Hope it helps.
> >>
> >> Anyway, now I've let the matter out about small business profiles,
> >> what do folk think about it? There has been a lot of interest from
> >> modellers and early adopters of UBL.
> >>
> >> Catering for Schemas for completely fresh documents might
> >> be the subject of another message later.
> >>
> >> All the best
> >>
> >> Stephen Green
> >>
> >
>
>
>