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

 


Help: OASIS Mailing Lists Help | MarkMail Help

set message

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


Subject: Re: [set] The topic of the next meeting...


An obvious requirement is for interoperability
between subsets.

Main use cases:

1. One or more subsets have a difference of namespace to the other subsets

  a. there is a model to which all the subsets conform

   i. there is a set of core components to for all of model

   ii. there are core components for some of the model

   iii. there are no core components for this model but
there are core components for another model (perhaps
an earlier version of the model) which is closely related
to the subsets' shared model

  b. at least one subset is based on a similar but not
identical model to the model on which the other
subsets are based

   i. all models have core components

   ii. some but not all models have core components

   iii. no models have core components


2. All subsets have the same namespace and there is
a single set of schemas to which each document
conforms

Same a, b i,ii,iii as above - in other words these use
cases form a table of three dimensions. Each
dimension could map to a 'dimension or variablility'.
(I won't attempt to create and populate such a table
because the dimensions need to grow beyond just
three. Dimensions of variability is a concept I'm
familiar with from the work of the OASIS Test
Assertions Guidelines TC and prior referenced works.)

Three of the dimensions for subsets are then

D1. Namespace variation (loose subsets where
variation of namespace is allowed)
D2. Model variation
D3. Core Component variation

Are there other similar dimensions of variability for
subsets? E.g.

D4. Core Component harmonisation (e.g. TBG17)

The next set of use cases to consider are extensions
of the same base language. Because they share the
same base language, they may all share a common
subset of the base language plus non-common parts
of the base language plus perhaps some common
extensions plus some individual, non-common
extensions. Each may have its own set of dimensions
of variability. The subsets may have D1, D2, D3, D4 at
least. There may be slightly different dimensions of
variability for the extensions:

D1. Namespaces - inevitable that extensions will
have different namespaces but also might be more
likely that all elements of the extended syntax will
have a namespace different to that of the base (e.g.
Swedish SFTI extended version of UBL 1.0 Invoice)

D2. Models - each model most likely to be very different
for extensions

D3. Core Components - possibly that this is only thing
extensions have in common

D4. Not all extensions will have been harmonised as
harmonisation takes some time, requires standard
body or industry backing and favours initial usage to
prove the requirement of new core components (e.g.
Hong Kong University's approach to CC projects). D4
may also include variability of which core components
are used (US Gov, I understand, have their own and
others may use CEFACT's) and levels of progress
through levels in a harmonisation process which may
have different top levels such as CEFACT TBG17 or
some other harmonisation top level.

A third set of use case will be based on interoperability
between languages which are different but all seek to
conform (in presence or absence of conformance
clauses) to CCTS (Core Component Technical
Specification). Here D3 and D4 apply of course but
there will be other dimensions such as:

D5. Usage of XML or EDI, etc
D6. Variations in datatypes
D7. NDRs
etc.

Best regards

Stephen Green

2008/7/15  <asuman@srdc.metu.edu.tr>:
> Dear Colleagues,
>
> During our next meeting we will address the requirements of electronic business document interoperability.
>
> Although we are all familiar with these problems, before we proceed any further it will be good to gather the specific requirements and use cases that you might have and wish to be discussed. So I look forward to receiving your input briefly describing the requirements or use cases by August 4, 2008, Monday.
>
> Thank you,
>
> Asuman
>
>



-- 
Stephen D. Green

Partner
SystML, http://www.systml.co.uk
Tel: +44 (0) 117 9541606
Associate Director
Document Engineering Services
http://www.documentengineeringservices.com

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice


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