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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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


Subject: Re: Question on CCTs vs Data Types


Fred,

Excellent points - please see comments below.

<Quote1>
1. In the next version of the spreadsheet TBG17 has entered all CCT's as
Data Types  without restrictions. This could also be done by registry
implementors. You avoid  special "slots" for CCT's but you pre-register
them as data types.
</Quote1>

That sounds better - I'll consider adding this point to the Technical
Note using an RFC 2119 "may" for implementers. Regarding slots, there
actually would still need to be slots to represent some of the CCTS
metadata. Some of the metadata attributes (Data Type name is one
example) map directly to existing registry attributes, while others
(such as Data Type qualifiers) will require slots. But this is ok, as
long as slots are used efficiently (i.e. so that we don't have slots
that will never contain any values).

<Quote2>
2. It seems to me that it depends on the functions of the registry
whether or not  CCT's should be registered. They impose limitations on
and give certain attributes to the DT's that are based on them, so for
consistency checking the CCT-information  should be there. We coded
DT/CCT relations in the spreadsheet macro's.
</Quote2>

Given that in the registry, all CCT attributes (that is, those of the
Supplementary Component and Content Component) will need to be
associated with Data Types (or stay on the CCT and remain empty), I
don't see how CCTs could impose any limitations on/given certain
attributes to the Data Types that are based on them. Any further details
that can clear this up would be very much appreciated.

<Quote3>
3. A special case are the DT's based on secondary representation terms
of CCT's, like Time (secondary representation term of date/time). These
need to be restricted the right way.
</Quote3>

The secondary representation terms can be represented as attributes of
Data Types in the registry, using multiple slots. Not sure what you mean
by "restricted the right way" - could you please give more specifics?

Thanks!
Joe

"Fred Blommestein, van" wrote:
> 
> Hi Joe,
> 
> Three final (?) remarks:
> 
> 1. In the next version of the spreadsheet TBG17 has entered all CCT's as
> Data Types  without restrictions. This could also be done by registry
> implementors. You avoid  special "slots" for CCT's but you pre-register
> them as data types.
> 
> 2. It seems to me that it depends on the functions of the registry
> whether or not  CCT's should be registered. They impose limitations on
> and give certain attributes to the DT's that are based on them, so for
> consistency checking the CCT-information  should be there. We coded
> DT/CCT relations in the spreadsheet macro's.
> 
> 3. A special case are the DT's based on secondary representation terms
> of CCT's, like Time (secondary representation term of date/time). These
> need to be restricted the right way.
> 
> Fred
> 
> -----Original Message-----
> From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> Sent: donderdag 4 december 2003 13:28
> To: Fred Blommestein, van
> Cc: Alan.Stitzer@marsh.com; blantz@attglobal.net; CCRev
> Subject: Re: Question on CCTs vs Data Types
> 
> Thanks again Fred - this resolves theses issues for me. Please see
> comments below:
> 
> <Quote1>
> Values of these attributes are restricted by means of facets. Facets can
> define the list of allowed values, the length, a pattern, etc. TBG17
> uses a spreadsheet for submission of BIE's, CC's, DT's and their facets.
> I attached it for illustration. The spreadsheet doesn't have any status:
> it is just a tool for TBG17. I send it only to illustrate the format of
> registry submissions. </Quote1>
> 
> There is no mention of CCT anywhere in this spreadsheet, which confirms
> my base suspicion that we really should not be registering CCTs in the
> registry - i.e. the attributes listed in the CCTS for Supplementary
> Components (Code List ID, Agency,etc.) really should be associated with
> Data Types. This is exactly the confirmation that I was looking for.
> 
> <Quote2>
> CCT's, according to CCTS, are Registry Classes, so it should be possible
> to register them. Even if all facets are blank (all values allowed) you
> can register their names and definitions. </Quote2>
> 
> Thanks - I will take that into account while writing the Technical Note.
> The primary importance is that I consider the registry architecture, and
> not give implementers something that will be too heavyweight to
> implement. So I may simply omit the registration of CCTs altogether (for
> now I cannot see a strong reason to register them with empty facets,
> which would be a waste of technical resources), and include the
> definitions in the Technical Note rather than in the registry. The CCT
> will be evident from the Representation Term "Slot" on the Data Type
> registry class.
> 
> Thanks again!
> Joe
> 
> "Fred Blommestein, van" wrote:
> >
> > Joe,
> >
> > <Quote1>
> > The "attributes" in the PCX file (like Identification Scheme.
> > Identifier) ARE Supplementary Components of the CCT Identifier. Type.
> > </Quote1>
> >
> > >Ok, but what would example values be for each of these attributes?
> >
> > Values of these attributes are restricted by means of facets. Facets
> > can define the list of allowed values, the length, a pattern, etc.
> > TBG17 uses a spreadsheet for submission of BIE's, CC's, DT's and their
> 
> > facets. I attached it for illustration. The spreadsheet doesn't have
> > any status: it is just a tool for TBG17. I send it only to illustrate
> > the format of registry submissions.
> >
> > <Quote2>
> > Right. The CCT's are listed exhaustively in the normative CCTS itself,
> 
> > so are not subject to user registration. A registry implementation
> > could pre-register them though. </Quote2>
> >
> > >I should have been more specific here. I meant to say that these
> > >appear to be unregisterable - whether by user, or pre-registered. So
> > >what I meant to say is that, according to my intepretation of the
> > >CCTS, it is impossible to register a CCT as represented in the CCTS
> > >because a CCT (e.g. "Identifier. Type") is much too generic to have
> > >attributes such as  "Identification Scheme. Identifier", etc. - but
> > >with example values (as requested above) my perception of this may
> > >change.
> >
> > CCT's, according to CCTS, are Registry Classes, so it should be
> > possible to register them. Even if all facets are blank (all values
> > allowed) you can register their names and definitions.
> >
> > <Quote3>
> > Hmmm, I'd hope that the CCTS features will be regular features in the
> > ebXML registry, and not "cutom" slots. </Quote3>
> >
> > >The OASIS/ebXML Registry TC decided quite a while ago that we would
> > >not create new "hardcoded" (or extrinsic, as we say) classes for Core
> 
> > >Components. Rather, we would create a Technical Note that would
> > >instruct implementors how to customize their implementations for Core
> 
> > >Components in a standard way using Slots to represent the metadata
> > >attributes in the CCTS.
> >
> > OK, fair enough. That's an implementation decision.
> >
> > <Quote4>
> > Well, this has been discussed at length within CCTS and the conclusion
> 
> > was that your "Base BCC" is in fact a Data Type. So please don't
> > introduce a new proprietary concept! </Quote4>
> >
> > >Thanks, I will definitely keep that in mind in writing the Technical
> > >Note. A question, please: referencing CCTS p.12 example, we have a
> > >Data Type called "Country" (Country. Identifier). We will need to
> > >represent the valid list of Country Codes for this Data Type. Can you
> 
> > >please tell me how this would be done, starting with the lowest level
> 
> > >of CCT? This is where I'm not clear, and I'm seeing discrepancies in
> > >the CCTS.
> >
> > In the spreadsheet are entries of a number of DT's, including Country_
> 
> > Identifier. Unfortunately we did not yet fill in all facets of the
> > Country_ Identifier. We filled in facets though of a number of other
> > DT's. It is not difficult to see what those Country_ Identifier facets
> 
> > would be:
> >
> > Identifier. Content: Length: 2, Pattern (expression): AA
> > Identification Scheme. Identifier: ISO 3166-1 Identification Scheme.
> > Name. Text: ISO 3166-1 Country Codes Identification Scheme. Agency.
> > Identifier: ISO 3166/MA Identification Scheme. Agency Name. Text: ISO
> > 3166 Maintenance Agency Identification Scheme. Version. Identifier:
> > 2003
> >
> > If there would be a webservice to resolve the country codes its URI
> > and the URI of the webservice schema could be listed in the last two
> > Supplementary Components (note that ISO offers updated XML versions of
> 
> > the list free of charge nowadays).
> >
> > Hope this helps,
> >
> > Fred
> >
> >
> >
> > "Fred Blommestein, van" wrote:
> > >
> > > Hi Joe,
> > >
> > > >Thanks Fred. I believe that these actually cannot be restrictions,
> > > >because - according to CCTS requirement [S33] (please pardon my
> > > >citing things that you already know - it's only for our discussion
> > > >purposes), Stored Supplementary Component Restrictions "shall only
> > > >be used to restrict the possible values of the Supplementary
> > > >Component of the Core Component Type on which the Data Type is
> > > >based". There is no mention of restricting the attributes listed in
> 
> > > >the PCX file (provided to me by Alan Stitzer), such as
> > > >Identification Scheme. Identifier, etc.
> > >
> > > The "attributes" in the PCX file (like Identification Scheme.
> > > Identifier) ARE Supplementary Components of the CCT Identifier.
> > > Type.
> > >
> > > >Additionally, Content Component restrictions - according to [S31] -
> 
> > > >"shall only be used to define format restrictions on the Primitive
> > > >Type of the Content Component of the Core Component Type on which
> > > >the Data Type is based.". Again, no sign of this in the PCX file.
> > >
> > > The Content Component (Identifier. Content) is also an entry in the
> > > PCX file.
> > >
> > > >Lastly, if the PCX file did denote a restriction on the Identifier.
> 
> > > >Type CCT, that implies that there must be values for these
> > > >attributes, for the Identifier. Type CCT. That begs the question:
> > > >What would these values be? For example, what single value could
> > > >one provide for "Identification Scheme. Identifier" for a CCT
> > > >called "Identifier. Type"? This is too generic an entity to provide
> 
> > > >such specific values.
> > >
> > >
> > >
> > > Exactly! So the Content and Supplementary Components of a CCT will
> > > not be restricted (other than their Primitive Type demands). The
> > > Supplementary Component and Content Component values of DT's will be
> 
> > > restricted (as they are more specific).
> > >
> > > >The way I interpret things, when factoring in the ebXML Registry
> > > >architecture, is that the most generic low-level entity that one
> > > >can register given the entities and metadata in the CCTS is
> > > >something like "Country_Identifier" - i.e. "Identifier. Type" does
> > > >not seem to be "registerable" given the entities and metadata in
> > > >the CCTS.
> > >
> > > Right. The CCT's are listed exhaustively in the normative CCTS
> > > itself, so are not subject to user registration. A registry
> > > implementation could pre-register them though.
> > >
> > > >Unless I am severely misinterpreting the CCTS (which I hope I am),
> > > >I believe that there may be some "metadata misplacement" issues
> > > >with the CCTS entities. I would be very happy to be proven wrong on
> 
> > > >this.
> > >
> > > I sure hope you are wrong here :-) !
> > >
> > > By now I don't see any misplacement issues.
> > >
> > > >By "slot" I mean a "custom" metadata attribute in the registry.
> > > >This is the ebXML Registry's mechanism extensibility mechanism - so
> 
> > > >for example, if one registered a schema and wanted to include
> > > >metadata such as "Used by Federal Agency", they would add a "Slot"
> > > >in the registry (speaking very generally) so that this information
> > > >could be recorded along with the schema.
> > >
> > > Hmmm, I'd hope that the CCTS features will be regular features in
> > > the ebXML registry, and not "cutom" slots.
> > >
> > > >Yes, our Technical Note will include more inheritance mechanisms as
> 
> > > >they make sense, mostly likely to include BIEs as well (haven't yet
> 
> > > >reached that point). For example, at the BCC level, we will provide
> 
> > > >the ability to register a "Base BCC" such as "Vendor. Code" that
> > > >can be associated with multiple ACCs, to yield BCCs such as
> > > >"PurchaseOrder. Vendor. Code" and "Invoice. Vendor. Code".
> > >
> > > Well, this has been discussed at length within CCTS and the
> > > conclusion was that your "Base BCC" is in fact a Data Type. So
> > > please don't introduce a new proprietary concept!
> > >
> > > Fred
> > >
> > > Kind Regards,
> > > Joe
> > >
> > > "Fred Blommestein, van" wrote:
> > > >
> > > > Joe,
> > > >
> > > > In my interpretation a Data Type is based on (further restricts) a
> 
> > > > CCT. So the entries in the table in your PCX file on Country_
> > > > Identifier. Type must be interpreted as restrictions to the values
> 
> > > > of the Content and Supplemental Components of the CCT Identifier.
> > > > Type.
> > > >
> > > > Hope this helpes.
> > > >
> > > > Fred
> > > >
> > > >         -----Original Message-----
> > > >         From: Alan.Stitzer@marsh.com
> [mailto:Alan.Stitzer@marsh.com]
> > > >         Sent: Mon 01/12/2003 20:10
> > > >         To: chiusano_joseph@bah.com; Fred Blommestein, van
> > > >         Cc: blantz@attglobal.net
> > > >         Subject: Re: Question on CCTs vs Data Types
> > > >
> > > >
> > > >
> > > >         Fred,
> > > >
> > > >         can you help me out here.....
> > > >
> > > >         This is what Joe is questioning:
> > > >
> > > >         (Embedded image moved to file: pic14720.pcx)
> > > >
> > > >         ajs
> > > >
> > > >
> > > >
> > > >
> > > >         <<< Memo from chiusano_joseph@bah.com@Internet on 01
> December, 2003, 13:37
> > > >         Monday >>>
> > > >
> > > >
> > > >         chiusano_joseph@bah.com@Internet on 1 Dec 2003, 13:37
> > > > Monday
> > > >
> > > >         To:    Alan Stitzer
> > > >         cc:    blantz; regrep-cc-review
> > > >         Subject:    Re: Question on CCTs vs Data Types
> > > >
> > > >
> > > >         Alan,
> > > >
> > > >         Please feel free to remove the CC Review address when you
> reply (since
> > > >         you're not a listserv member, you're getting that error).
> > > >
> > > >         Regarding the attached file: It appears to "span" 2
> entities in the
> > > >         CCTS: Data Type and CCT. By that, I mean it specifies that
> "Country.
> > > >         Identifier. Type" (doesn't matter for the purposes of this
> question
> > > >         whether it is a Code or Identifier type) is a Data Type,
> yet it provides
> > > >         the metadata (Identification Scheme. Identifier, etc.) for
> a CCT (i.e.
> > > >         the attributes listed are those of a Supplementary
> Component, which is
> > > >         associated with a CCT). How can this be possible, given
> Figure 7-1 in
> > > >         the CCTS?
> > > >
> > > >         Thanks in advance for your help,
> > > >         Joe Chiusano and the Core Components Review SC
> > > >
> > > >         Alan.Stitzer@marsh.com wrote:
> > > >         >
> > > >         > Joe,
> > > >         >
> > > >         > I get this email bounced back to me:
> > > >         > regrep-cc-review@lists.oasis-open.org
> > > >         >
> > > >         > as taken from the TBG17 initial dictionary, this is what
> Country_
> > > >         > Identifier. Type looks like:
> > > >         >
> > > >         > (Embedded image moved to file: pic23038.pcx)
> > > >         >
> > > >         > ajs
> > > >         >
> > > >         > <<< Memo from chiusano_joseph@bah.com@Internet on 01
> December, 2003,
> > > >         12:21
> > > >         > Monday >>>
> > > >         >
> > > >         > chiusano_joseph@bah.com@Internet on 1 Dec 2003, 12:21
> Monday
> > > >         >
> > > >         > To:    Alan Stitzer
> > > >         > cc:    blantz; regrep-cc-review
> > > >         > Subject:    Re: Question on CCTs vs Data Types
> > > >         >
> > > >         > Thanks Alan. I would like to take your answer a step
> further, if it's
> > > >         > ok:
> > > >         >
> > > >         > Since "Country_Code" is a Data Type, it has the
> following CCTS
> > > >         > requirement:
> > > >         >
> > > >         > [S29] Stored Data Types shall have a Core Component Type
> as their basis.
> > > >         >
> > > >         > Given that, we would have the following CCT requirement:
> > > >         >
> > > >         > [S19] Core Component Types are a particular category of
> Core Components.
> > > >         > As such, stored Core Component Types shall include all
> Attributes of
> > > >         > stored Core Components.
> > > >         >
> > > >         > Given that, we would have the following "Store Component
> Components"
> > > >         > requirement (explanations are snipped):
> > > >         >
> > > >         > [S1] Core Components are a particular category of
> Registry Classes. As
> > > >         > such, all stored Core Components shall include the
> following Attributes:
> > > >         >
> > > >         > ? Unique Identifier (mandatory)
> > > >         > ? Version (mandatory)
> > > >         > ? Dictionary Entry Name (mandatory)
> > > >         > ? Definition (mandatory)
> > > >         > ? Usage Rule (optional, repetitive)
> > > >         >
> > > >         > What would the value for the "Dictonary Entry Name"
> attribute be for the
> > > >         > corresponding CCT? Would it be "Code. Type"? If so, how
> can one specify
> > > >         > the "Supplementary Component" attributes for the
> "Country_Code" Data
> > > >         > Type (code list ID, agency, etc.) if they are tied to a
> single CCT
> > > >         > called "Code. Type"?
> > > >         >
> > > >         > Thanks in advance for your help,
> > > >         > Joe Chiusano and the Core Components Review SC
> > > >         >
> > > >         > >
> > > >         > > Joe,
> > > >         > >
> > > >         > > >Is an entity named "Country_Code" a CCT or a Data
> Type? I interpret it
> > > >         > > >as a CCT.
> > > >         > >
> > > >         > > Without getting into a debate that has raged on and on
> and on and
> > > >         > > on....that would be a data type, however, we believe
> that it is an
> > > >         > > identifier rather than a code.
> > > >         > >
> > > >         > > TBG17 has a defined data type called Country_
> Identifier -- which
> > > >         > restricts
> > > >         > > the CCT identifier to the "correct" country (aarrgghh)
> code list.
> > > >         > >
> > > >         > > ____________________
> > > >         > > Alan Stitzer
> > > >         > > AVP
> > > >         > > Marsh USA Inc.
> > > >         > > 1166 Avenue of the Americas
> > > >         > > New York, NY 10036-2774
> > > >         > > Phone: (561) 743-1938
> > > >         > > Fax: (561) 743-1993
> > > >         > > Internet: Alan.Stitzer@marsh.com
> > > >         > > ____________________
> > > >         > >
> > > >         > > <<< Memo from chiusano_joseph@bah.com@Internet on 01
> December, 2003,
> > > >         > 11:51
> > > >         > > Monday >>>
> > > >         > >
> > > >         > > chiusano_joseph@bah.com@Internet on 1 Dec 2003, 11:51
> Monday
> > > >         > >
> > > >         > > To:    Alan Stitzer; blantz
> > > >         > > cc:    regrep-cc-review
> > > >         > > Subject:    Question on CCTs vs Data Types
> > > >         > >
> > > >         > > Mary Kay and Alan,
> > > >         > >
> > > >         > > We (the OASIS/ebXML Registry Core Components Review
> SC) have a question
> > > >         > > on CCTs vs Data Types that we hope you can answer for
> us, as I don't
> > > >         > > believe the answer is clear from the CCTS (or I have
> misinterpreted the
> > > >         > > CCTS):
> > > >         > >
> > > >         > > Is an entity named "Country_Code" a CCT or a Data
> Type? I interpret it
> > > >         > > as a CCT.
> > > >         > >
> > > >         > > More details:
> > > >         > >
> > > >         > > - According to Gunther's CCT document (XML
> representations), I believe
> > > >         > > that Country_Code would be considered a CCT.
> > > >         > >
> > > >         > > - The issue underlying the question is that the CCTS
> lists multiple
> > > >         > > Supplementary Component attributes (code list ID,
> agency, etc.) which -
> > > >         > > I believe - would need to be tied to a specific code
> list (such as
> > > >         > > "Country_Code") rather than a generic CCT called
> "Code. Type".
> > > >         > >
> > > >         > > - I'm sure how/why we would register a generic CCT
> called "Code. Type"
> > > >         -
> > > >         > > i.e. what values would the attributes (code list ID,
> agency, etc.)
> > > >         have?
> > > >         > >
> > > >         > > - So a more "specific" Country_Code - e.g.
> European_Country_Code -
> > > >         would
> > > >         > > be a Data Type (not a CCT), which restricts the CCT
> called
> > > >         > > "Country_Code" to inlcude only those codes from
> European countries.
> > > >         > >
> > > >         > > Thanks in advance for your help,
> > > >         > > Joe Chiusano and the Core Components Review SC
> > > >         > > (See attached file: Chiusano_Joseph.vcf)
> > > >         > >
> > > >         > > To:    Alan Stitzer/NYC-NY/US/Marsh/MMC@MMC,
> > > >         > blantz@attglobal.net@Internet
> > > >         > > cc:    regrep-cc-review@lists.oasis-open.org@Internet
> > > >         > > From:  chiusano_joseph@bah.com@Internet
> > > >         > (See attached file: Chiusano_Joseph.vcf)
> > > >         >
> > > >         > To:    Alan Stitzer/NYC-NY/US/Marsh/MMC@MMC
> > > >         > cc:    blantz@attglobal.net@Internet,
> > > >         >        regrep-cc-review@lists.oasis-open.org@Internet
> > > >         > From:  chiusano_joseph@bah.com@Internet
> > > >         >
> > > >         >
> > > >
> ------------------------------------------------------------------------
> > > >         >                           Name: pic23038.pcx
> > > >         >    pic23038.pcx           Type: PCX Image
> > > >         (application/x-unknown-content-type-pcxfile)
> > > >         >                       Encoding: base64
> > > >         >                Download Status: Not downloaded with
> message
> > > >
> > > >
> > > >
> > > >         To:    Alan Stitzer/NYC-NY/US/Marsh/MMC@MMC
> > > >         cc:    blantz@attglobal.net@Internet,
> > > >                regrep-cc-review@lists.oasis-open.org@Internet
> > > >         From:  chiusano_joseph@bah.com@Internet
> > > >
> > > >
> > > >
> > > >
> > > > -------------
> > > > Dit e-mailbericht en enige bijlage is vertrouwelijk en uitsluitend
> 
> > > > bestemd voor de geadresseerde(n). Indien u niet de geadresseerde
> > > > bent, mag u deze e-mail of enige bijlage niet kopieren of aan
> > > > derden ter inzage geven of verspreiden. Indien u deze e-mail per
> > > > vergissing heeft ontvangen verzoeken wij u de afzender ervan
> > > > onmiddellijk op de hoogte te stellen per e-mail en de betreffende
> > > > e-mail te vernietigen.
> > > >
> > > > This e-mail and any attachment is confidential and may contain
> > > > legally privileged information. If you are not the intended
> > > > recipient, please note that this e-mail or any attachment may not
> > > > be copied or disclosed or distributed to others. If you have
> > > > received this e-mail by error, please notify the sender
> > > > immediately by return e-mail, and delete this message.
> > > > --------------
> > >
> > > -------------
> > > Dit e-mailbericht en enige bijlage is vertrouwelijk en uitsluitend
> > > bestemd voor de geadresseerde(n). Indien u niet de geadresseerde
> > > bent, mag u deze e-mail of enige bijlage niet kopieren of aan derden
> 
> > > ter inzage geven of verspreiden. Indien u deze e-mail per vergissing
> 
> > > heeft ontvangen verzoeken wij u de afzender ervan onmiddellijk op de
> 
> > > hoogte te stellen per e-mail en de betreffende e-mail te
> > > vernietigen.
> > >
> > > This e-mail and any attachment is confidential and may contain
> > > legally privileged information. If you are not the intended
> > > recipient, please note that this e-mail or any attachment may not be
> 
> > > copied or disclosed or distributed to others. If you have received
> > > this e-mail by error, please notify the sender immediately by return
> 
> > > e-mail, and delete this message.
> > > --------------
> >
> > -------------
> > Dit e-mailbericht en enige bijlage is vertrouwelijk en uitsluitend
> > bestemd voor de geadresseerde(n). Indien u niet de geadresseerde bent,
> 
> > mag u deze e-mail of enige bijlage niet kopieren of aan derden ter
> > inzage geven of verspreiden. Indien u deze e-mail per vergissing heeft
> 
> > ontvangen verzoeken wij u de afzender ervan onmiddellijk op de hoogte
> > te stellen per e-mail en de betreffende e-mail te vernietigen.
> >
> > This e-mail and any attachment is confidential and may contain legally
> 
> > privileged information. If you are not the intended recipient, please
> > note that this e-mail or any attachment may not be copied or disclosed
> 
> > or distributed to others. If you have received this e-mail by error,
> > please notify the sender immediately by return e-mail, and delete this
> 
> > message.
> > --------------
> >
> >
> ------------------------------------------------------------------------
> >                                     Name: CC-BIE-DT-harm-0-4.xls
> >                                     Type: Microsoft Excel Worksheet
> (application/vnd.ms-excel)
> >    CC-BIE-DT-harm-0-4.xls       Encoding: base64
> >                              Description: CC-BIE-DT-harm-0-4.xls
> >                          Download Status: Not downloaded with message
> 
> -------------
> Dit e-mailbericht en enige bijlage is vertrouwelijk en
> uitsluitend bestemd voor de geadresseerde(n). Indien u niet
> de geadresseerde bent, mag u deze e-mail of enige bijlage niet
> kopieren of aan derden ter inzage geven of verspreiden.
> Indien u deze e-mail per vergissing heeft ontvangen
> verzoeken wij u de afzender ervan onmiddellijk op de hoogte te
> stellen per e-mail en de betreffende e-mail te vernietigen.
> 
> This e-mail and any attachment is confidential and may
> contain legally privileged information. If you are not the
> intended recipient, please note that this e-mail or any
> attachment may not be copied or disclosed or distributed to
> others. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
> --------------
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


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