HM.Requirements:
HumanML must represent, in an explicit and
clear fashion, the values as they make sense to the conveyers themselves
themselves, as best as possible within the limits of XML design...no one
else needs to be consulted, or should be consulted, except the designated
authority creating these self-definitions.
Ranjeeth Kumar
Thunga
Doesn't this get back into the argument we had
before about this? We're saying "How do you define happiness?"? Even not
getting into deep root causes, the definition of happiness in any context is
going to be extraordinarily difficult. It almost makes me wonder whether
instead of arguing over level we should instead define some form of
context:
<happiness level="ecstatic"
xlink:def="http://www.hml.org/schemas/happiness/tokens"/>
where xlink:def would in turn point to a specific
schema instance, such as:
<schema>
<element name="happiness"
type="Happiness"/>
<complexType
name="Happiness">
<attribute name="level" type="Happiness_Level>
</complexType>
<simpleType
name="Happiness_Level" type="String">
<restrictions>
<enumeration value="ecstatic"/>
<enumeration value="buzzed"/>
<enumeration value="amused"/>
<enumeration value="inlove"/>
<enumeration value="sad"/>
</restrictions>
</simpleType>
</schema>
By changing the xlink pointer, you could also
change the way that any given element is interpreted:
<happiness level="35"
xlink:def="http://www.hml.org/schemas/happiness/percent"/>
<schema>
<element name="happiness"
type="Happiness"/>
<complexType
name="Happiness">
<attribute name="level" type="Happiness_Level>
</complexType>
<simpleType
name="Happiness_Level" type="non-negativeInteger">
<restrictions>
<minValueInclusive value="0"/>
<maxValueInclusive
value="100"/>
</restrictions>
</simpleType>
</schema>
The above would give you a happiness level
between 0 and 100 inclusive. You could conceivably also define a default
schema that said that if no xlink:def element, level is assumed to have a
value between 0 and 1 inclusive.
This gives us a mechanism for bypassing all of
the potential arguments about HumanML -- the element names and structure fall
under the context of the HumanML, but the interpretation of these names become
a matter for the application developer. By specifically assigning the
schemas in this manner, you can also establish a set of mechanisms for
interpretation between schemas via a language such as XSLT: For instance, if
<happiness> #1 uses http://www.hml.org/schemas/happiness/tokens
and <happiness> #2 uses http://www.hml.org/schemas/happiness/percent,
then you could create a simple map:
<xsl:template match="happiness">
<copy>
<xsl:attribute
name="level">
<xsl:for-each select="@level">
<xsl:choose>
<xsl:when test=". = 'ecstatic'
">100</xsl:when>
<xsl:when test=". = 'buzzed' ">70</xsl:when>
<xsl:when test=". = 'amused'
">40</xsl:when>
<xsl:when test=". = 'inlove'
">65</xsl:when>
<xsl:when test=". = 'sad'
">0</xsl:when>
<xsl:otherwise>50</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</xsl:attribute>
</copy>
</xsl:template>
</xsl:stylesheet>
The specific maps could also be associated
with a given RDF document:
This basically says that any time you need to
translate from happiness/tokens to happiness/percent, you would use
happiness_tokens2percent.xsl.
-- Kurt Cagle