Issue 9300: Wrong Stereotypes for Property Types
Issue 9349: Simple Property Datatype
Issue 9582: Waveform Response to Audio Device RTS Signal
Issue 9583: ConcreteDataPdu: New Attributes
Issue 9584: Stream / Channel - Parameters
Issue 10414: Unregister Operation Issues
Issue 10419: Domain Register Operation Issues
Issue 10420: Section H; evaluate error conditions
Issue 10588: Erroneous reference in PIM & PSM for SW Radio dtc/06-04-18
Issue 10638: DTD XML Relationships Oversight
Issue 11242: issue in section 7.1.4 of SWRadio Component Framework Spec (formal/07-03-04
Issue 11418: Definition of Complex type
Issue 13932: Implementation Properties
Issue 9300: Wrong Stereotypes for Property Types (swradio-rtf)
Click here for this issue's archive.
Source: Raytheon (Mr. Gerald Lee Bickle, Gerald.L.Bickle(at)raytheon.com)
Nature: Uncategorized Issue
Severity:
Summary:
Wrong Stereotypes for Property Types. Make struct property and test def property types stereotypes of datatype instead of class in the properties. These should be treated type definitions not classes. EnumerationProperty?
Simple Property Datatype. This allows users to form common definitions that can be used for components properties. A data/primitive stereotype that similar tags as RadioProperty. Add to properties section.
Discussion: This issue is deferred to the follow-on RTF, since RTF #1 ran out of time. Disposition: Deferred
The following issue was raised in the SDR Forum's SCA WG: The PTT function is a oneway call and the audio device does not wait for an RTS signal. This situation prevents the waveform from providing a negative response to the PTT. If the waveform is unable to transmit data at the time of a PTT, does the waveform just ignore/drop the data without alerting the audio device or user through some specified mechanism?
Discussion: This issue is deferred to the follow-on RTF, since RTF #1 ran out of time. Current rational is that a RTS management is a function of the waveform as opposed to the audio device. A specialization to support this could be done. Further discussion with the SDR Forum is needed to fully understand the requirements. Disposition: Deferred
The following issue was raised in the SDR Forum's SCA WG: The group was concerned that without a control structure along with the data payload, the Audio API might impose unnecessary constraints. Discussion within the group identified that a control structure containing at least a Stream Id, a Payload Length, and a Sequence number could provide much greater flexibility that the API as currently stated
Discussion: This issue is deferred to the follow-on RTF, since RTF #1 ran out of time. Payload Length is built into the OctetSequence (delegate this problem to the PSM). The other two parameters would need the SimplePDU to instantiate it to conform to what is needed (this could include payload length as well). SimplePDU is a basic building block. It is unclear however how pervasive the use of these parameters are. If all audio devices need this data then these data could be supported. If a subset of devices would use this information, then specialize it. Further discussion with the SDR Forum is needed to fully understand the requirements. Disposition: Deferred
The following issue was raised in the SDR Forum's SCA WG: The Audio API does not include an interface for configuring or exchanging information that is specific to a stream or channel. Such information might include: quality of service parameters, packet size, symbol size, priority, and audio codec.
Discussion: This issue is deferred to the follow-on RTF, since RTF #1 ran out of time. Further discussion with the SDR Forum is needed to fully understand the requirements (more complete set and the use cases under which they are used). Disposition: Deferred
Problem The domain manager and device manager unregister operations take in an object reference, which cannot be used directly for determining what component to unregister since one cannot compare on object references, so a callback is needed to get the identifier for unregistering service thus being inefficient. Proposed Solution: Replace the unregistering operations and remove device parameters with an unregistering identifier parameter of string type. This change affects CompositeDevice, DeviceManagerRegistration and ServiceRegistration interfaces.
Discussion: This issue is deferred to the follow-on RTF, since RTF #1 ran out of time. Disposition: Deferred
Issue: The domain manager register operations take in an object reference, so a callback is needed to get the identifier and profile attributes thus being inefficient. Extent of Change: Major Resolution: Add to the DeviceManagerRegistration interface operations, identifier and profile parameters to eliminate the callbacks.
Discussion: This issue is deferred to the follow-on RTF, since RTF #1 ran out of time. Disposition: Deferred
The base POSIX version of the AEP is being updated within the specification. In the update a new set of Error Conditions has been defined. The new error conditions need to be evaluated in order to determine whether or not they should be included within the specification.
Discussion: This issue is deferred to the follow-on RTF, since RTF #1 ran out of time. Disposition: Deferred
In Section 6.1 of the PIM & PSM for SW Radio intro book dtc/06-04-18, currently under DTC vote, one finds these references to Life Science specs: =============================== * Life Sciences Identifiers (LSID) - There are many cross references in the model defined by this specification. They are expressed using LSIDs. The relevant specification is available as OMG documents: formal/04-12-01 and dtc/04-08-03. * Genomic Map (GM) - The definitions in GM specification are either too limiting or too generic for SNPs purposes. The GM was designed at the time when genetic maps were the only genome wide maps. Current focus is on sequence maps. =============================== Presumably this is a cut-n-paste error/artifact, and should be repaired. The reference to BQS may be spurious as well.
I believe there is an error in Figure 7.1 in the "Component Document Type Definition Specification" dtc/06-04-22. Please note that the "DevicePackageDescriptor" is NOT showing any dependency on "Properties". This is a defined relationship in SCA 2.2.2. Proposed Resolution: DPD ----> (0..*) Properties
Table 7.2 shows 11 stereotypes, but the 7.1.4 subsections support only 2 of them (RequiresPort and StreamPort). The other 9 are NOT detailed.
Recommendation: Complex data type should be defined in UML Profile for SWRadio. Resolution: Mark have requested SBC DTF to consider this problem.
The meta-model needs to allow implementation properties (e.g., entry point arguments for environment types) to be defined at the implementation level