[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [humanmarkup] PBS-Doc-humlNameElements
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-2309http://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