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] New Base Schema Elements and Attributes - humlCommAtts

Title: New Base Schema Elements and Attributes - humlCommAtts
Hi Everyone,

Rather than attempt to remember our exchange today, I am including Ranjeeth's earlier message about this topic and my reply, so that we can proceed from here.

I think we can put this particular issue to rest fairly easily if we follow the same formula Len pioneered for us in humlIdentifierAtts and give humlCommAtts or humlCommIdentifierAtts exactly the same properties: xsd:ID and xsd:string and say that it exists to supply unique names for elements that deal with communications per se. That means that many of the existing elements will change from having humlIdentifierAtts to having humlCommAtts or humlCommIdentifierAtts. We would need to decide whether or not the shorter term is enough or we need the jawbreaker version.


To: Ranjeeth Kumar Thunga <rkthunga@humanmarkup.org>, humanmarkup@lists.oasis-open.org, humanmarkup-comment@lists.oasis-open.org
From: Rex Brooks <rexb@starbourne.com>
Subject: Re: [humanmarkup-comment] FW: [humanmarkup] Base Schema - global  attributes, attribute groups and datatype definition(s)
Okay for now, but if you could remember this when we take up the new attributeGroup, I will still be bringing it up in its own separate thread for the record. This thread is still on the strawman toolkit, so if we could keep that straight, I would appreciate it.

However, I will also try to remember for the record that I think command is a type of statement not the other way around. You can have a statement that is not a command, but not a command that is not also a statement, at least verbally. Consider something as simple as "Do this," or "Don't do that." We might want to defer to an expert on thist, if we can agree on one.

Regardless, I'm still not convinced that these are attributes. I think I would prefer them to be elements in their own rights in the Secondary. I think we need to be very careful that we don't paint ourselves into a corner with this. It's another one of those things that could persuade the public that we are out of bounds trying to classify things in ways that the wider communities do not.

But I will have to give it more thought myself. It won't be long until we have the thread fired up. Our list of new elements is short and we only have this one new attributeGroup.


At 2:10 PM -0400 10/15/02, Ranjeeth Kumar Thunga wrote:
Quick comment regarding enumerating the CommAtts attribute (set) with values and typesŠI believe it isn't worth enumerating values within the PSBŠalthough I was tempted to push for it, I believe the feedback from you and Len was that these lists wouldn't be truly primitive.  I was thinking along the lines of "statement, question, command, other", but there are others and finer shadesŠstatements, questions, or commands, can serve multiple purposes, and there are other ways of breaking down communication.
The only truly primitive component of communication, which I feel should be in the PSB at this point, is some sort of 'acknowledgement' attribute, with 3 possible values.
Required - (question, command, Š.)
Optional - (statement, declaration, Š)
None - (rhetorical question, faceGesture...)
Ranjeeth Kumar Thunga
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