[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [humanmarkup] Base Schema-humlNameAtts
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
Attachment:
xNAL.xsd
Description: Mac BinHex archive
Attachment:
PersonName-1_2.xsd
Description: Mac BinHex archive
Attachment:
PostalAddress-1_2.xsd
Description: Mac BinHex archive
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC