FYI
------ Forwarded Message
From: "Crawford, Mark" <mark.crawford@xxxxxxx>
Date: Thu, 12 Apr 2007 18:35:38 -0700
To: "Stuhec, Gunther" <gunther.stuhec@xxxxxxx>
Cc: <irvchmielewski@xxxxxx>, <alain.chapdaniel@xxxxxxxxxxx>,
<anderst@xxxxxxxxxxxxx>, <andreas.schultz@xxxxxxx>, <Aschoka@xxxxxxxxxxx>,
<bogdanfy@xxxxxxxxxxxxx>, <buchinski.ed@xxxxxxxxxxxxx>,
<debra.cimbala@xxxxxxxxxxxxx>, <dill@xxxxxxxxx>, <diskray@xxxxxxxxxxxxxxxx>,
<edgar.gluck@xxxxxxx>, <F.De_Vos@xxxxxxxxxx>,
<francis.berthomieu@xxxxxxxxxxxxxxxxx>, <frank.vandamme@xxxxxxxxx>,
<fred@xxxxxxxxxxxxx>, <fvuille@xxxxxxxxxxxxx>, <garret.minakawa@xxxxxxxxxx>,
<Gilles.Brandel@xxxxxxx>, <hsedi@xxxxxxxxxxxxx>,
<ivan.bendini@xxxxxxxxxxxxxxxxx>, <james.whittle@xxxxxxxxxxxx>,
<jbarrett@xxxxxxxxxxx>, <jean_luc_champion@xxxxxxxxx>,
<jlsmith@xxxxxxxxxxx>, <john.bezant@xxxxxxxxxxxxxx>,
<kenji.itoh@xxxxxxxxxxxxx>, <klambert@xxxxxxx>, <kris.ketels@xxxxxxxxx>,
<kumarsivaraman@xxxxxxxxxxxxx>, <marianne.khouzam@xxxxxxx>,
<marion.royal@xxxxxxx>, <Michael.Onder@xxxxxxxxxxxx>,
<mollyaanderson@xxxxxxxxx>, <mrowell@xxxxxxxxxxxxxxxxxxxx>,
<nada_reinprecht@xxxxxxxxxxxxx>, <nivezic@xxxxxxxx>,
<olli-pekka.pauna@xxxxxxxxxxxx>, <paula.heilig@xxxxxxxxxxxxx>,
<phruby@xxxxxxxxxxxxx>, <plothian@xxxxxxxxxxxx>, <rachelf@xxxxxxxxxxxxx>,
<sally.m.chan@xxxxxxxxxx>, <serm@xxxxxxxx>, <srudelic@xxxxxxxx>,
<sutterst@xxxxxxxxxxxxxx>, <tripathi@xxxxxxxxxxxxx>, <yavo@xxxxxxxxxxx>,
<yunker@xxxxxxxxxx>, <jim.wilson@xxxxxxx>,
<fabrice.bourge@xxxxxxxxxxxxxxxxx>, Øyvind Aassve <oyvind@xxxxxxxxxxxx>,
Jean-Luc SANSON <jean-luc.sanson@xxxxxx>, <tripathi@xxxxxxxxxxx>, "Dietrich,
Jens (Finanzen) Ref-36" <Jens.Dietrich@xxxxxxxxxxxxxxxxxx>,
<sue.probert@xxxxxxxxxxxxxx>, Stig Korsgaard <STK@xxxxxxxxxxxxxxx>, Duane
Nickull <dnickull@xxxxxxxxx>, Mary Kay Blantz <mblantz@xxxxxxxxxxxxx>,
<Gilman.Daniel@xxxxxxx>, <abcoates@xxxxxxxxxxxxxx>, Gait Boxman
<gait.boxman@xxxxxx>
Conversation: Final 3.0 Draft
Subject: Final 3.0 Draft (01)
Gunther, (02)
Attached is the final 3.0 draft for tomorrow. We need to review 5 examples
and 1 definition before release. (03)
Kind Regards, (04)
Mark (05)
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@xxxxxxxxx]
> Sent: Tuesday, March 06, 2007 12:56 PM
> To: sue.probert@xxxxxxxxxxxxxx; Stig Korsgaard; Mary Kay
> Blantz; abcoates@xxxxxxxxxxxxxx; Gait Boxman
> Cc: Stuhec, Gunther; alain.chapdaniel@xxxxxxxxxxx;
> anderst@xxxxxxxxxxxxx; andreas.schultz@xxxxxxx;
> Aschoka@xxxxxxxxxxx; bogdanfy@xxxxxxxxxxxxx;
> buchinski.ed@xxxxxxxxxxxxx; Crawford, Mark;
> debra.cimbala@xxxxxxxxxxxxx; dill@xxxxxxxxx;
> diskray@xxxxxxxxxxxxxxxx; edgar.gluck@xxxxxxx;
> F.De_Vos@xxxxxxxxxx; francis.berthomieu@xxxxxxxxxxxxxxxxx;
> frank.vandamme@xxxxxxxxx; fred@xxxxxxxxxxxxx;
> fvuille@xxxxxxxxxxxxx; garret.minakawa@xxxxxxxxxx;
> Gilles.Brandel@xxxxxxx; Gilman.Daniel@xxxxxxx;
> hsedi@xxxxxxxxxxxxx; irvchmielewski@xxxxxx;
> ivan.bendini@xxxxxxxxxxxxxxxxx; james.whittle@xxxxxxxxxxxx;
> jbarrett@xxxxxxxxxxx; jean_luc_champion@xxxxxxxxx;
> jlsmith@xxxxxxxxxxx; john.bezant@xxxxxxxxxxxxxx;
> kenji.itoh@xxxxxxxxxxxxx; klambert@xxxxxxx;
> kris.ketels@xxxxxxxxx; kumarsivaraman@xxxxxxxxxxxxx;
> marianne.khouzam@xxxxxxx; marion.royal@xxxxxxx;
> Michael.Onder@xxxxxxxxxxxx; mollyaanderson@xxxxxxxxx;
> mrowell@xxxxxxxxxxxxxxxxxxxx; nada_reinprecht@xxxxxxxxxxxxx;
> nivezic@xxxxxxxx; olli-pekka.pauna@xxxxxxxxxxxx;
> paula.heilig@xxxxxxxxxxxxx; phruby@xxxxxxxxxxxxx;
> plothian@xxxxxxxxxxxx; rachelf@xxxxxxxxxxxxx;
> sally.m.chan@xxxxxxxxxx; serm@xxxxxxxx; srudelic@xxxxxxxx;
> sutterst@xxxxxxxxxxxxxx; tripathi@xxxxxxxxxxxxx;
> yavo@xxxxxxxxxxx; yunker@xxxxxxxxxx; jim.wilson@xxxxxxx;
> fabrice.bourge@xxxxxxxxxxxxxxxxx; Øyvind Aassve; Jean-Luc
> SANSON; tripathi@xxxxxxxxxxx; Dietrich, Jens (Finanzen) Ref-36
> Subject: Re: Cardinality and TBG17
>
> Now I am confused. I thought that the parent container
> should logically
> declare the cardinality. Are you talking about data elements
> making an
> ecapsulated reference to cardinality that is to be used as a
> restrictive
> tenet for all contextual uses of that element? Wouldn't that
> logically
> severely limit the re-use with little or no benefit? An
> element does not
> declare its own cardinality, a construct that uses it does.
> Therefore B*'s
> should not have a notion ipso facto, only A*'s.
>
> I also see huge issues if you use an encapsulated model for
> cardinality
> logic. The same type of thing breaks XML Schema if you an make a
> declaration like this:
>
> <xs:Element name="foo">
> </xs:Choice>
> <xs:Element name="bar" minOccurs="1" />
> <xs:Element name="bah" minOccurs="1" />
> ...
> </xs:Choice>
>
> Note the conflict in logic. What should have happened here
> is that Foo is
> 100% responsible for declaring the cardinality of all
> children elements.
> Bar and bah should not decide how many times they are
> appearing and the
> overall semantics of the construct should be used as a logic guide.
>
> Or am I way off base here??
>
> D
>
>
> On 3/6/07 7:50 AM, "Sue Probert" <sue.probert@xxxxxxxxxxxxxx> wrote:
>
> > I vote for option 2 but with the provisos that
> >
> > a) If just one BBIE is based on a BCC specified with the
> cardinality 0:1 then
> > that BBIE MAY be specified as either optional or mandatory
> i.e. 0:1 or 1:1.
> >
> > b) if multiple BBIEs are present each based on the same BCC
> specified with the
> > cardinality 0:1 then none of them can be specified to be
> mandatory i.e. each
> > MUST be 0:1.
> >
> > Similarly for any BCC specified as 1:1 I would say that
> >
> > a) If just one BBIE is based on a BCC specified with the
> cardinality 1:1 then
> > that BBIE MUST also be specified as mandatory i.e. 1:1.
> >
> > b) if multiple BBIEs are present each based on the same BCC
> specified with the
> > cardinality 1:1 then again none of them can be specified to
> be mandatory i.e.
> > each MUST be 0:1.
> >
> > To me the difference between these two cases is that the
> usage rules for the
> > implementation of the BBIEs would have to specify that:
> >
> > a) in the case of the 0:1 BCC one of the BBIEs defined, but
> only one, MAY be
> > used in a syntax instance
> >
> > b) in the case of the 1:1 BCC one of the BBIEs defined, but
> only one, MUST be
> > used in a syntax instance
> >
> > cheers
> >
> > Sue
> >
> >
> > -----Original Message-----
> > From: Stig Korsgaard [mailto:STK@xxxxxxxxxxxxxxx]
> > Sent: 06 March 2007 15:24
> > To: Mary Kay Blantz; abcoates@xxxxxxxxxxxxxx; Gait Boxman
> > Cc: Duane Nickull; Stuhec, Gunther; alain.chapdaniel@xxxxxxxxxxx;
> > anderst@xxxxxxxxxxxxx; andreas.schultz@xxxxxxx; Aschoka@xxxxxxxxxxx;
> > bogdanfy@xxxxxxxxxxxxx; buchinski.ed@xxxxxxxxxxxxx; Crawford, Mark;
> > debra.cimbala@xxxxxxxxxxxxx; dill@xxxxxxxxx;
> diskray@xxxxxxxxxxxxxxxx;
> > edgar.gluck@xxxxxxx; F.De_Vos@xxxxxxxxxx;
> > francis.berthomieu@xxxxxxxxxxxxxxxxx; frank.vandamme@xxxxxxxxx;
> > fred@xxxxxxxxxxxxx; fvuille@xxxxxxxxxxxxx;
> garret.minakawa@xxxxxxxxxx;
> > Gilles.Brandel@xxxxxxx; Gilman.Daniel@xxxxxxx; hsedi@xxxxxxxxxxxxx;
> > irvchmielewski@xxxxxx; ivan.bendini@xxxxxxxxxxxxxxxxx;
> > james.whittle@xxxxxxxxxxxx; jbarrett@xxxxxxxxxxx;
> > jean_luc_champion@xxxxxxxxx; jlsmith@xxxxxxxxxxx;
> > john.bezant@xxxxxxxxxxxxxx; kenji.itoh@xxxxxxxxxxxxx;
> klambert@xxxxxxx;
> > kris.ketels@xxxxxxxxx; kumarsivaraman@xxxxxxxxxxxxx;
> > marianne.khouzam@xxxxxxx; marion.royal@xxxxxxx;
> > Michael.Onder@xxxxxxxxxxxx; mollyaanderson@xxxxxxxxx;
> > mrowell@xxxxxxxxxxxxxxxxxxxx; nada_reinprecht@xxxxxxxxxxxxx;
> > nivezic@xxxxxxxx; olli-pekka.pauna@xxxxxxxxxxxx;
> > paula.heilig@xxxxxxxxxxxxx; phruby@xxxxxxxxxxxxx;
> plothian@xxxxxxxxxxxx;
> > rachelf@xxxxxxxxxxxxx; sally.m.chan@xxxxxxxxxx; serm@xxxxxxxx;
> > srudelic@xxxxxxxx; sue.probert@xxxxxxxxxxxxxx;
> sutterst@xxxxxxxxxxxxxx;
> > tripathi@xxxxxxxxxxxxx; yavo@xxxxxxxxxxx; yunker@xxxxxxxxxx;
> > jim.wilson@xxxxxxx; fabrice.bourge@xxxxxxxxxxxxxxxxx; Øyvind Aassve;
> > Jean-Luc SANSON; tripathi@xxxxxxxxxxx; Dietrich, Jens
> (Finanzen) Ref-36
> > Subject: RE: Cardinality and TBG17
> >
> >
> > I vote for keeping option one.
> >
> > If BCC in the ACC is 0..1 - Only option is none BBIE, one
> BBIE 0..1 or one
> > BBIE 1..1 allowed in the ABIE.
> >
> >
> > Best Regards
> >
> > Stig Korsgaard
> > M.Sc.E Standardisation Manager
> > Tel: +45 3370 1083
> > Cell: +45 3016 1083
> > Mail: stk@xxxxxxxxxxxxxxx
> >
> > Danish Bankers Association
> > Amaliegade 7
> > DK-1256 Copenhagen K
> > Tel: 3370 1000
> > Fax: 3393 0260
> > mail@xxxxxxxxxxxxxxx
> > www.finansraadet.dk
> >
> > -----Original Message-----
> > From: Mary Kay Blantz [mailto:mblantz@xxxxxxxxxxxxx]
> > Sent: 2. marts 2007 13:47
> > To: abcoates@xxxxxxxxxxxxxx; Gait Boxman
> > Cc: Duane Nickull; Stuhec, Gunther; alain.chapdaniel@xxxxxxxxxxx;
> > anderst@xxxxxxxxxxxxx; andreas.schultz@xxxxxxx; Aschoka@xxxxxxxxxxx;
> > bogdanfy@xxxxxxxxxxxxx; buchinski.ed@xxxxxxxxxxxxx; Crawford, Mark;
> > debra.cimbala@xxxxxxxxxxxxx; dill@xxxxxxxxx;
> diskray@xxxxxxxxxxxxxxxx;
> > edgar.gluck@xxxxxxx; F.De_Vos@xxxxxxxxxx;
> > francis.berthomieu@xxxxxxxxxxxxxxxxx; frank.vandamme@xxxxxxxxx;
> > fred@xxxxxxxxxxxxx; fvuille@xxxxxxxxxxxxx;
> garret.minakawa@xxxxxxxxxx;
> > Gilles.Brandel@xxxxxxx; Gilman.Daniel@xxxxxxx; hsedi@xxxxxxxxxxxxx;
> > irvchmielewski@xxxxxx; ivan.bendini@xxxxxxxxxxxxxxxxx;
> > james.whittle@xxxxxxxxxxxx; jbarrett@xxxxxxxxxxx;
> jean_luc_champion@xxxxxxxxx;
> > jlsmith@xxxxxxxxxxx; john.bezant@xxxxxxxxxxxxxx;
> kenji.itoh@xxxxxxxxxxxxx;
> > klambert@xxxxxxx; kris.ketels@xxxxxxxxx;
> kumarsivaraman@xxxxxxxxxxxxx;
> > marianne.khouzam@xxxxxxx; marion.royal@xxxxxxx;
> Michael.Onder@xxxxxxxxxxxx;
> > mollyaanderson@xxxxxxxxx; mrowell@xxxxxxxxxxxxxxxxxxxx;
> > nada_reinprecht@xxxxxxxxxxxxx; nivezic@xxxxxxxx;
> > olli-pekka.pauna@xxxxxxxxxxxx; paula.heilig@xxxxxxxxxxxxx;
> > phruby@xxxxxxxxxxxxx; plothian@xxxxxxxxxxxx; rachelf@xxxxxxxxxxxxx;
> > sally.m.chan@xxxxxxxxxx; serm@xxxxxxxx; srudelic@xxxxxxxx;
> Stig Korsgaard;
> > sue.probert@xxxxxxxxxxxxxx; sutterst@xxxxxxxxxxxxxx;
> tripathi@xxxxxxxxxxxxx;
> > yavo@xxxxxxxxxxx; yunker@xxxxxxxxxx; jim.wilson@xxxxxxx;
> > fabrice.bourge@xxxxxxxxxxxxxxxxx; yvind Aassve; Jean-Luc SANSON;
> > tripathi@xxxxxxxxxxx; Dietrich, Jens (Finanzen) Ref-36
> > Subject: Cardinality and TBG17
> >
> > Hi,
> >
> > We need a very clear answer on this one; glad to see all
> the discussion.
> >
> > A BCC has a cardinality of 0..1.
> >
> > There are two possibilities for the BBIEs:
> >
> > 1) A max of one BBIE based on that BCC is permitted. This
> is what TBG17 is
> > doing now.
> >
> > 2) An unlimited number of BBIEs based on that BCC are
> permitted. They
> > would be differentiated by qualification of the Property
> Term, and would be
> > either 1..1 or 0..1.
> >
> > Cheers,
> > Mary Kay
> >
> > PS Please avoid the 'but there could be a lot of BBIEs in
> different ABIEs
> > based on the ACC'. We know that part.
> >
> > ----- Original Message -----
> > From: "Anthony B. Coates (Miley Watts)" <abcoates@xxxxxxxxxxxxxx>
> > To: "Gait Boxman" <gait.boxman@xxxxxx>
> > Cc: "Duane Nickull" <dnickull@xxxxxxxxx>; "Stuhec, Gunther"
> > <gunther.stuhec@xxxxxxx>; <alain.chapdaniel@xxxxxxxxxxx>;
> > <anderst@xxxxxxxxxxxxx>; <andreas.schultz@xxxxxxx>;
> <Aschoka@xxxxxxxxxxx>;
> > <bogdanfy@xxxxxxxxxxxxx>; <buchinski.ed@xxxxxxxxxxxxx>;
> "Crawford, Mark"
> > <mark.crawford@xxxxxxx>; <debra.cimbala@xxxxxxxxxxxxx>;
> <dill@xxxxxxxxx>;
> > <diskray@xxxxxxxxxxxxxxxx>; <edgar.gluck@xxxxxxx>;
> <F.De_Vos@xxxxxxxxxx>;
> > <francis.berthomieu@xxxxxxxxxxxxxxxxx>; <frank.vandamme@xxxxxxxxx>;
> > <fred@xxxxxxxxxxxxx>; <fvuille@xxxxxxxxxxxxx>;
> <garret.minakawa@xxxxxxxxxx>;
> > <Gilles.Brandel@xxxxxxx>; <Gilman.Daniel@xxxxxxx>;
> <hsedi@xxxxxxxxxxxxx>;
> > <irvchmielewski@xxxxxx>; <ivan.bendini@xxxxxxxxxxxxxxxxx>;
> > <james.whittle@xxxxxxxxxxxx>; <jbarrett@xxxxxxxxxxx>;
> > <jean_luc_champion@xxxxxxxxx>; <jlsmith@xxxxxxxxxxx>;
> > <john.bezant@xxxxxxxxxxxxxx>; <kenji.itoh@xxxxxxxxxxxxx>;
> > <klambert@xxxxxxx>; <kris.ketels@xxxxxxxxx>;
> <kumarsivaraman@xxxxxxxxxxxxx>;
> > <marianne.khouzam@xxxxxxx>; <marion.royal@xxxxxxx>;
> > <Michael.Onder@xxxxxxxxxxxx>; <mollyaanderson@xxxxxxxxx>;
> > <mrowell@xxxxxxxxxxxxxxxxxxxx>; <nada_reinprecht@xxxxxxxxxxxxx>;
> > <nivezic@xxxxxxxx>; <olli-pekka.pauna@xxxxxxxxxxxx>;
> > <paula.heilig@xxxxxxxxxxxxx>; <phruby@xxxxxxxxxxxxx>;
> > <plothian@xxxxxxxxxxxx>; <rachelf@xxxxxxxxxxxxx>;
> <sally.m.chan@xxxxxxxxxx>;
> > <serm@xxxxxxxx>; <srudelic@xxxxxxxx>; <stk@xxxxxxxxxxxxxxx>;
> > <sue.probert@xxxxxxxxxxxxxx>; <sutterst@xxxxxxxxxxxxxx>;
> > <tripathi@xxxxxxxxxxxxx>; <yavo@xxxxxxxxxxx>; <yunker@xxxxxxxxxx>;
> > <jim.wilson@xxxxxxx>; <fabrice.bourge@xxxxxxxxxxxxxxxxx>;
> "Mary Kay Blantz"
> > <mblantz@xxxxxxxxxxxxx>; "yvind Aassve"
> <oyvind@xxxxxxxxxxxx>; "Jean-Luc
> > SANSON" <jean-luc.sanson@xxxxxx>; <tripathi@xxxxxxxxxxx>;
> "Dietrich, Jens
> > (Finanzen) Ref-36" <Jens.Dietrich@xxxxxxxxxxxxxxxxxx>
> > Sent: Friday, March 02, 2007 7:34 AM
> > Subject: Re: Glossary definition: restriction
> >
> >
> >> On Fri, 02 Mar 2007 12:12:48 -0000, Gait Boxman
> <gait.boxman@xxxxxx>
> >> wrote:
> >>
> >>> What it means is that the BCC may appear on instances of
> the ACC. Of
> >>> course we decided those instances don't exist, so we have
> to infer that
> >>> to BIE. So assuming the 0..1 BCC has an equivalent BBIE
> in context X,
> >>> and the ACC has an equivalent ABIE in context X, what are
> the possible
> >>> cardinalities for BBIE in ABIE following restriction?
> >>> Well, 1..1 works, it's in 0..1, 0..0 also works, and so
> does 0..1. What
> >>> wouldn't work is anything repeatable.
> >>
> >> ACCs don't have instances, only ABIEs (and other BIEs).
> The point I was
> >> making was whether the upper bound applies to individual
> derived BBIEs, or
> >> to all of the derived BBIEs taken together as a group.
> That is the point
> >> where we have found different people have been taking different
> >> interpretation.
> >>
> >>>> It throws up the question of whether CCs should have
> cardinalities at
> >>>> all. Indeed, the overwhelming majority are
> 0..unbounded, but there are
> >>>> some that are 0..1, and with specific intent, so we need
> to decide what
> >>>> that means.
> >>> If we drop cardinality we might as well drop content
> models altogether.
> >>
> >> And I wasn't suggesting we want to drop cardinality in
> CCs, just that if
> >> we have it, it has to have a clear meaning and usage.
> >>
> >>>> Remember, though, that what CCTS is most worried about is the
> >>>> derivation of content models. That is the focus of the
> CCTS spec. I
> >>>> would suggest that from a CCTS perspective, European
> Address and Dutch
> >>>> Address would restrictions of the Address ACC, but the
> Dutch Address
> >>>> would not be considered to be a restriction of the
> European Address
> >>>> (since restriction doesn't allow you to remove a
> mandatory item, as
> >>>> that is an extension of cardinality).
> >>> Help, since when is the Netherlands outside of Europe? If
> we can't use
> >>> restriction along the natural context axis for
> geopolitical axis we're
> >>> in for an enormous problem. That's the whole principle of
> context driven
> >>> specialization.
> >>
> >> No, that isn't the principle, not as I understand it. The
> principle is
> >> that you should be able to use business context to select
> the appropriate
> >> BIEs for a message (or perhaps even to produce appropriate
> "anonymous"
> >> BIEs on the fly for a message). That means that you need
> to be able to
> >> select the Dutch Address for a Dutch message based on its
> context, or to
> >> select the European Address is that is what the business context
> >> requires. It doesn't means that the Dutch Address BIE needs to be
> >> directly derivable from the European Address BIE. In that
> direction lies
> >> madness, because data structures simply don't follow
> business context that
> >> closely.
> >>
> >>>> Now, from a separate UCM/CCMA perspective, clearly the
> business context
> >>>> of a Dutch Address (i.e. "netherlands") is a
> >>>> subset/restriction/narrowing of the business context of
> a European
> >>>> Address ("europe"). That's something that needs to be taken into
> >>>> account in CCMA, but is different to the "restriction"
> process that we
> >>>> are describing in the CCTS glossary, primarily so that
> when we talk
> >>>> about "restriction" in the CCTS spec, people know what
> we are referring
> >>>> to.
> >>> I'm not prepared to start doing things differently in
> CCMA for things
> >>> that should follow CCTS. If restriction means something
> different in
> >>> CCMA than in CCTS the only thing we can say is that
> somebody messed up
> >>> totally. CCMA is in the same (semantic) domain as CCTS.
> >>> While I appreciate that XML type restriction is something
> different,
> >>> that has very little to do with CCTS or CCMA restriction concepts.
> >>
> >> I'm not saying that CCMA should "do things differently" in
> any practical
> >> sense. The point is that English, in spite of its
> attempts to subsume the
> >> vocabularies of numerous languages, still has far fewer
> words than the
> >> number of distinct concepts that we need to describe. So
> we "overload"
> >> words and give them multiple meanings. The point I am
> making is that we
> >> have an overloaded usage of "restriction" here. There is data
> >> restriction, and there is semantic domain restriction. These are
> >> different things. For the CCTS glossary, I was suggesting
> that we define
> >> restriction in a way that covers its usage in the CCTS
> spec, which is a
> >> way that would be appropriate for some other specs. The
> alternative is to
> >> have a multi-part definition with the different meanings
> of "restriction",
> >> a bit like the dictionary entry for "set". That would be
> appropriate for
> >> a separate CEFACT glossary document, but I think it would
> be overkill for
> >> the glossary in the CCTS spec (but comments and
> disagreements to that are
> >> welcome).
> >>
> >> Cheers, Tony.
> >> --
> >> Anthony B. Coates
> >> Senior Partner
> >> Miley Watts LLP
> >> Experts In Data
> >> +44 (79) 0543 9026
> >> Data standards participant: ISO 20022 (ISO 15022 XML), ISO 19312,
> >> UN/CEFACT TMG, MDDL, FpML, UBL.
> >> http://www.mileywatts.com/
> >>
> >
> >
> >
> >
>
> --
> **********************************************************
> Sr. Technical Evangelist - Adobe Systems, Inc. *
> Chair - OASIS SOA Reference Model Technical Committee *
> Blog: http://technoracle.blogspot.com *
> Music: http://www.mix2r.com/audio/by/artist/duane_nickull*
> **********************************************************
>
> (06)
------ End of Forwarded Message (07)
CCTS3p0 2nd Public Review 16 AprilFinalDraft12Apr.pdf
Description: Binary data
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|