OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (SAF-11) Symptom Grouping/Linking



    [ http://tools.oasis-open.org/issues/browse/SAF-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=25003#action_25003 ] 

Stavros Isaiadis  commented on SAF-11:
--------------------------------------

In relation to extensibility in the "RelatedSymptoms" field and elsewhere, after looking around, I think the following two approaches may be interesting:

-	We have a field called Extension which denotes a nonexistent relationship, and which is then defined in an attribute:

<xsd:simpleType name="RelatedSymptomsEnumType">
    <xsd:restriction base="xsd:string">
        <xsd:enumeration value="Causal"/>
        <xsd:enumeration value="Supersedes"/>
        <xsd:enumeration value="Repetition"/>
        <xsd:enumeration value="Other"/>
    </xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="RelatedSymptomsType">
    <xsd:simpleContent>
        <xsd:extension base="RelatedSymptomsEnumType">
            <xsd:attribute name="other" type="xsd:string"/>
        </xsd:extension>
    </xsd:simpleContent>
</xsd:complexType>			

<xsd:element name="RelatedSymptoms" type="RelatedSymptomsType"/>

This is my favorite approach but creates the need of RelatedSymptoms relationship to be an element and not simply an attribute as we have it in the proposal right now...

-	Second approach uses a xsd:union, and pretty much makes recommendations as to the values, but allows any kind of string to be used

<xsd:simpleType name="SuggestedRelatedSymptomsType">
    <xsd:restriction base="xsd:string">
        <xsd:enumeration value="Causal"/>
        <xsd:enumeration value="Supersedes"/>
        <xsd:enumeration value="Repetition"/>
    </xsd:restriction>
</xsd:simpleType>

<xsd:simpleType name="RelatedSymptomsType">
	<xsd:union memberTypes="SuggestedRelatedSymptomsType xsd:string"/>
</xsd:simpleType>

<xsd:element name="RelatedSymptoms" type="RelatedSymptomsType"/>

	This works with the attributes as we have it now, but validation of enumeration types cannot happen by the parser now (but only in a secondary step). I'm also not sure whether the support for xsd:union is problematic or not.


> Symptom Grouping/Linking
> ------------------------
>
>                 Key: SAF-11
>                 URL: http://tools.oasis-open.org/issues/browse/SAF-11
>             Project: OASIS Symptoms Automation Framework (SAF) TC
>          Issue Type: Task
>            Reporter: Jeffrey Vaught
>            Assignee: Alvin Black
>            Priority: Critical
>
> In the pre standards phase of this work, it was suggested that some form of "Group Id" or "Linking Tag" be included at the top level of the Symptom to indicate that this Symptom was in someway related to other Symptoms and that this relationship was identifiable by the creator of the Symptom.
> Notes
> •	Jeff: Could capture in the signature, but emitter is uniquely positioned to provide.
> •	Alvin: On/Off (state).  Alarmid.
> •	Vivian: Prototypes show this is important for performance.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]