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

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup message

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


Subject: RE: [humanmarkup] PBS-Doc-humlNameElements


Title: RE: [humanmarkup] PBS-Doc-humlNameElements
Hi John,

I will review the Guide and unless someone gives me a better reason not to do so, I will make sure that we are in accord with it. To be honest, I am really just following the example of our phase 0 schema, which I adapted. I was probably advised to consult this guide, since I correspond fairly frequently with Owen Ambur, co-chair of the xml.gov working group and we have an unofficial liaison  person with ebXML with whom I also correspond more frequently since she is also a member of the Web Services for Interactive Applications TC.

Thanks for bringing this to our attention.

Ciao,
Rex

At 7:18 PM -0700 10/24/02, Aerts, John F. wrote:
I appoligize for not having reviewed your elements but I would like to pose a question? Are you following the the Draft Federal Developers Guide for XML and ISO 11179 data elements standards?
 
Why are your elements using lower camel case?( humlNameElements)
 
I think XNL , XAL and XNAL are all following the Federal Developers Guide. http://www.oasis-open.org/committees/ciq/download.shtml
 
Draft Federal XML Developer's Guide             http://xml.gov/documents/in_progress/developersguide.pdf
 
ISO 11179: Specification and Standardization of Data Elements  http://www.diffuse.org/meta.html#ISO11179
 
You may want to review the information at http://www.ebtwg.org/projects/core.html
 
Core Components Technical Draft v.1.8  http://www.ebtwg.org/projects/documentation/core/CoreComponentsTS1.80.pdf
 
Lieutenant John Aerts
Los Angeles County Sheriff's Department
Records & Identification Bureau
Consolidated Criminal History Reporting System (CCHRS) Manager
 
Phone 562 465 7876
Fax 323 415 2666
e-mail aerts@lasd.org
Web www.lasd.org


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Wednesday, October 23, 2002 12:35 PM
To: humanmarkup@lists.oasis-open.org; cognite@zianet.com; clbullar@ingr.com; kurt@kurtcagle.net; mbatsis@netsmart.gr
Subject: [humanmarkup] PBS-Doc-humlNameElements

This was an element once upon a time but has metamorphosed into humlNameElements which is more accurate and does not conflict with our naming convention for global attributeGroups. However, it is still defined/described as Human Name Attributes as a set of attributes for documenting the names and alias of real of artifical humans, communities, businesses, etc.

I have grouped it with the complexTypes human and address as part of the Individual Human and Identity Section, which applies to names and addresses. This is also the section in which I will ask advice on whether or not to add a complextType for employment.



Subject: [humanmarkup-comment] Base Schema-humlNameAtts

             From: Rex Brooks <rexb@starbourne.com>
             To: humanmarkup-comment@lists.oasis-open.org
             Date: Sat, 31 Aug 2002 07:39:02 -0700


      Hi Everyone,

      I have to introduce a new wrinkle with this element, not only because
      this element is actually a set of attributes as opposed to a single
      issue element, as it were, but also because this element requires
      harmonization with two existing schemata, or to be accurate schemata
      of schemata in the same sense that metadata is data about data.

      Those two schemata are:

      OASIS Customer Information Quality TC schemata for XNL and XAL, or in
      combination XNAL, (eXtensible Name Language, eXtensible Address
      Language and eXtensible Name and Address Language); and

      Human Resources-XML Cosortium, PersonName-1.2.xsd and PostalAddress-1.2.xsd

      I am including the schemata for Address in these citations because
      this information also applies to Address, and I chose to ignore it in
      order to postpone this discussion until after we had a few elements
      under our collective belts so to speak. As it turns out, I guess I
      was experiencing a precognitive episode, or made an unconscious guess
      that when we got to this point, the Web Services TCs would also be
      close to pushing their first spec out the door, too. Or maybe it just
      worked out that way. Regardless, the time has come to start doing the
      hard work of harmonizing these various standards, and humlNameAtts is
      the place to start. AND for beginning the work of actively liaising
      with other TCs and standards groups.

      So, I have attached said documents to this message and I am asking
      for help. I really can't do all this. I still haven't had the time to
      fully explore the resources James Landrum has supplied for our
      Annotated Bibiliography,  which will need to be addressed in some way
      as references for included definitions, while we also stipulate that
      we are not excluding other definitions even as we make clear that our
      Primary Base Schema Elements are collected as the foundation upon
      which the extended schemata which use various specifically stipulated
      definitions for these elements can be built. That is a long-winded
      way of saying that we are not attempting to be the source for
      definitions of these elements. We are using operational, working
      definitions for our terms not detailed technical definitions specific
      to applications. We need to be inclusive not exclusive.

      So my question is: Should we include the specific definitions given
      in these associated schemata or should be cite them and how should
      those citations be constructed? As you may have noticed, I have not
      yet started the standard examination of the element from the straw
      man because I think we need to look at this closer first, especially
      if we choose to cite these and/or other schemata from other standards
      bodies.

      This one needs some careful thought.

      Ciao,
      Rex
      --
--
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com


-- 
Rex Brooks
Starbourne Communications Design
1361-A Addison, Berkeley, CA 94702 *510-849-2309
http://www.starbourne.com * rexb@starbourne.com


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


Powered by eList eXpress LLC