[OASIS Issue Tracker] Commented: (SAF-10) Extensibility

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

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

Stavros Isaiadis  commented on SAF-10:
--------------------------------------

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. 


> Extensibility
> -------------
>
>                 Key: SAF-10
>                 URL: http://tools.oasis-open.org/issues/browse/SAF-10
>             Project: OASIS Symptoms Automation Framework (SAF) TC
>          Issue Type: Task
>            Reporter: Jeffrey Vaught
>            Assignee: Vivian Lee
>            Priority: Critical
>
> With the exception of open content in several places, this specification has omitted extensibility. Extensibility can help with the development of future versions of the specification and possible extensions. 
> Notes
> Vivian: JSTL, tacked on an open ended datatype for every entity.  Allow free content (at your own risk).  SAF uses extensibility for Protocol.Process, Symptom.Content, etc.  Allows extensibility for Practitioner, Symptoms Emitter.  But energy domain consumers (for example) may need additional fields that we haven't considered.  Use at your own risk

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