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] 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