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: [humanmarkup] PBS-Doc-humlNameElements


Title: 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


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


Powered by eList eXpress LLC