Re: [ubl] ACC? AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN HANGZHOU 9 MAY - 13 MAY 2005

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

Mark

> That is the part I don't yet understand - why a different namespace

This goes back to my finding that having the document namespace
for any BIE other than the document element causes a problem with
minor versions. The document schemas quite rightly (there are even
greater problems otherwise) have elementFormDefault="qualified"
so when you create a document instance, any locally declared
(document namespace) elements have no prefix. However, as I've
previously demonstrated
( http://lists.oasis-open.org/archives/ubl/200503/msg00001.html
though my conclusions in this mailing were subsequently changed)
the minor version for such a document schema would import the
previous version (if there were any changes) and then would not
have elementFormDefault="qualified" for that previous schema
of course, only for the new minor version document schema. This
means a change to any elements, apart from the document top
element, which previously had no prefix so that now they have to
have a prefix (with the previous version namespace of course).
This means that minor version changes are not so invlisible to
instance creators and to some kinds of instance-digesting software.
It means that a minor change of version needs more than a change
of schema location attribute values in an instance. Having every
document element in another namespace (or external schema module)
protects the instance creator and sensitive software from such
version changes (as my latest prototypes all prove, for example
http://lists.oasis-open.org/archives/ubl/200504/msg00108.html )

The decision to have everything globally declared was based on
a desire to solve these problems. At the time I was unaware that
the problem invloved more than just Codes and Identifiers and that
we had locally declared BIEs such as TaxPointDate,
LineItemCountNumeric and DespatchDocumentReference which
caused the problem too.

I'd really like to ask; why is LineItemCountNumeric
considered to be specific to a document? I can answer that - the reason
is not that it isn't usable in other documents (most documents have it)
but that it only exists in documents and not in the ABIEs defined
in the 'reusable' spreadsheet. TaxPointDate could be considered
Invoice-specific but isn't treated as such for that reason but just,
again, because it doesn't appear in any 'reasuable spreadsheet'
ABIEs (not deliberately, just because it is only ever defined at
the next-top-level of a document).

I think there are therefore modeling reasons to solve some of this
too (as has been raised at the plenary). I'd argue that if something
is reusable that won't always be obvoius to begin with and so that
might not be a good criterion to judge how it should appear in a
schema - but if it were the criterion then it should be modeled as
such, not arbitrarily. At present an ABIE can be designated reusable
in the model by including its 'Associated Object Class' in the
reusable spreadsheet since it is an ABIE. This cannot be applied to
BBIEs yet since they cannot exist yet on their own in the reusable
model spreadsheet - that is an issue we could try to resolve - or
we could just say that any BBIE in a document spreadsheet should
be declared in the common basic components schema module and referenced
from there in the document schema module so that its declaration
doesn't have to be local to the document. If the former, then we'd
need a separate namespace for it other than that of the document,
I think, if we are to avoid the problem explained above. We could
also say that all ABIEs with names which are qualified forms
of an 'Associated Object Class' , ABIEs which are not themselves
defined in the reusable model spreadsheet - these ABIEs either have
to be declared in the common aggregate components schema module or
in some other specially provided external schema module. This would
apply even if the BIEs were all derived (either conceptually perhaps or
with XSD derviation) from Core Components. (I do like the idea of using
the latter to ensure that restiction can better suit a BIE to its document
though).

** Another option might be just to have one namespace for a document
and another for a document-specific sub-element irrespective of which
module it is declared in but I've not tested this.

> The bloating and conflicts of the library are caused because we have
> tried to use BIEs in a way that was never intended - as the CC and BIE
> together.  As a result, the BIE is both a conceptual data model and a
> physical data model.  CCs are intended to be the kitchen sink that never
> ever get used for any purpose other than as a harmonization tool.  BIEs
> are supposed to be specific assemblies for specific contexts in specific
> exchanges - qualified and customized through restriction from the
> conceptual CC.

I agree - but it might be best (not tested though) to use XSD derivation
to derive the BIE from the CC, having the CCs in a 'core schema module'
perhaps for this purpose. The declarations of so-called 'document-specific'
BIE (if there really are such things) would still have to happen either
in external schema modules for the purpose or, if the namespace they are
given differs from the document top element's namespace, perhaps in the
document schema module. That's how I think it might work but again I
haven't tested it all, except for my finding as previously shown in
prototypes.

All the best

Stephen Green



----- Original Message ----- 
From: <MCRAWFORD@lmi.org>
To: <stephen_green@seventhproject.co.uk>; <ubl@lists.oasis-open.org>
Sent: Wednesday, May 18, 2005 4:04 PM
Subject: RE: [ubl] ACC? AW: [ubl] PLENARY REPORT FROM THE UBL TC MEETING IN
HANGZHOU 9 MAY - 13 MAY 2005




> This doesn't have any document specific BIEs and I can
> appreciate your point made earlier that there may be a
> requirement to have such.
>
> Having any document specific BIEs causes problems similar to
> those which required all Codes and Identifiers to be global -
> if the BIEs have the same namespace as the document - or so
> it seems from the work I've been doing with prototyping
> designs and checking their implications.

Could you please identify the problems

> So if we do need (I admit I can't see why very clearly) any
> document-specific BIEs then I think we'd possibly need an
> external schema module for them.

I guess I need to see the problems first before I could agree with this
assumption
>
> 2. I'd think an idea worth considering would be to have a
> document-specific module but with another namespace.

That is the part I don't yet understand - why a different namespace

>I'm thinking that in future it might be a suitable place to
> derive more suitable document specific types from common or
> core types so that, for example, an OrderLine in an Order
> doesn't have to include all the ASBIEs which are really there
> just for use in the OrderResponse

You just hit the nail on the head as to why we need Core Components.
With a core component of Line and BIEs of Order_Line and
OrderResponse_Line, you can segment the ASBIEs.

> This would cut down a lot on the overbloating of documents
> (one of the problems the SBS incidentally helps to solve).

The bloating and conflicts of the library are caused because we have
tried to use BIEs in a way that was never intended - as the CC and BIE
together.  As a result, the BIE is both a conceptual data model and a
physical data model.  CCs are intended to be the kitchen sink that never
ever get used for any purpose other than as a harmonization tool.  BIEs
are supposed to be specific assemblies for specific contexts in specific
exchanges - qualified and customized through restriction from the
conceptual CC.

Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php