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
- From: Rex Brooks <rexb@starbourne.com>
- To: humanmarkup-comment@lists.oasis-open.org, humanmarkup@lists.oasis-open.org
- Date: Tue, 15 Oct 2002 12:30:23 -0700
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.
Ciao,
Rex
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)
Cc:
Bcc:
X-Attachments:
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.
Ciao,
Rex
At 2:10 PM -0400 10/15/02, Ranjeeth Kumar Thunga wrote:
Quick comment regarding enumerating the CommAtts
attribute (set) with values and typesI believe it isn't worth
enumerating values within the PSBalthough 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 shadesstatements, 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...)
Comments?
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