OpenHome Forum
State variables names in scpd - Printable Version

+- OpenHome Forum (http://forum.openhome.org)
+-- Forum: OpenHome (/forumdisplay.php?fid=1)
+--- Forum: Net (/forumdisplay.php?fid=5)
+--- Thread: State variables names in scpd (/showthread.php?tid=1393)



State variables names in scpd - SiMet - 15-06-2015 12:18 PM

I've just created own ContentDirectory from working scpd.

I've notices that in orginal scdp I have State variable:
Code:
<stateVariable sendEvents="no">
<name>SortCapabilities</name>
<dataType>string</dataType>
</stateVariable>

However, in scpd generated by ohNet I get
Code:
<stateVariable sendEvents="no">
<name>A_ARG_TYPE_GetSortCapabilities_SortCaps</name>
<dataType>string</dataType>
</stateVariable>

Is it possible to change Variable name?
I searched if is posible to change Parameter name but didn't find anything.


RE: State variables names in scpd - simonc - 15-06-2015 12:26 PM

The only thing that has changed here is the name of a non-evented state variable. This provides the type (plus optional range) of an argument to an action; it is never referenced by action invocations or evented updates. The action and parameter names (GetSortCapabilities and SortCaps in this case) are unchanged so I'd expect well written control points to be entirely unaware of the name chosen for a non-evented state variable.

Does the current code cause you a specific problem? If it does, can you tell us more about it please?


RE: State variables names in scpd - SiMet - 15-06-2015 01:32 PM

As you mentioned well written control points should have no problem with such names.
However, if I'd like to make certification of such device UCTT ( UPnP Certification Test Tool ) rise error because of not existing state variable SortCapabilities and others which are required.


RE: State variables names in scpd - simonc - 16-06-2015 04:47 PM

(15-06-2015 01:32 PM)SiMet Wrote:  As you mentioned well written control points should have no problem with such names.
However, if I'd like to make certification of such device UCTT ( UPnP Certification Test Tool ) rise error because of not existing state variable SortCapabilities and others which are required.

Thanks for the explanation, I understand your issue now.

I think the current behaviour conforms to another UPnP forum spec so I might try reporting a bug against the compliance tool. I'll get back to you when we hear back about this.


RE: State variables names in scpd - SiMet - 18-06-2015 10:27 AM

Could you provide me some information about this spec which you think conforms to current behaviour?


RE: State variables names in scpd - simonc - 18-06-2015 01:17 PM

(18-06-2015 10:27 AM)SiMet Wrote:  Could you provide me some information about this spec which you think conforms to current behaviour?

In the v1.1 device architecture doc, 2.5 Service description says

state variables which are defined solely for the purpose of describing the type of an argument MUST have a name that includes the prefix “A_ARG_TYPE_"

The v1.0 architecture doc has a similar section, albeit with softer language (SHOULD rather than MUST).

The language in this section is a little imprecise but I read it as implying that the ContentDirectory is wrong to choose non-evented state variable names like "SortCapabilities".

It certainly seems wrong for the compliance tests to mandate that this questionable (or plain incorrect) form of naming must be followed.


RE: State variables names in scpd - SiMet - 19-06-2015 12:47 PM

(18-06-2015 01:17 PM)simonc Wrote:  
(18-06-2015 10:27 AM)SiMet Wrote:  Could you provide me some information about this spec which you think conforms to current behaviour?

In the v1.1 device architecture doc, 2.5 Service description says

state variables which are defined solely for the purpose of describing the type of an argument MUST have a name that includes the prefix “A_ARG_TYPE_"

The v1.0 architecture doc has a similar section, albeit with softer language (SHOULD rather than MUST).

The language in this section is a little imprecise but I read it as implying that the ContentDirectory is wrong to choose non-evented state variable names like "SortCapabilities".

It certainly seems wrong for the compliance tests to mandate that this questionable (or plain incorrect) form of naming must be followed.

I get from my friend that:
"ContentDirectory specification specifies exact state variables names. Please see the specification “UPnP-av-ContentDirectory-v1-Service-20020625.pdf” page 12, Table 7."


RE: State variables names in scpd - simonc - 19-06-2015 12:51 PM

(19-06-2015 12:47 PM)SiMet Wrote:  
(18-06-2015 01:17 PM)simonc Wrote:  In the v1.1 device architecture doc, 2.5 Service description says

state variables which are defined solely for the purpose of describing the type of an argument MUST have a name that includes the prefix “A_ARG_TYPE_"

The v1.0 architecture doc has a similar section, albeit with softer language (SHOULD rather than MUST).

The language in this section is a little imprecise but I read it as implying that the ContentDirectory is wrong to choose non-evented state variable names like "SortCapabilities".

It certainly seems wrong for the compliance tests to mandate that this questionable (or plain incorrect) form of naming must be followed.

I get from my friend that:
"ContentDirectory specification specifies exact state variables names. Please see the specification “UPnP-av-ContentDirectory-v1-Service-20020625.pdf” page 12, Table 7."

Thanks for this. I'd still claim it's incorrect that ContentDirectory violates a mandatory part of the UPnP spec.

We're running the compliance tool at present. We'll fix any errors we can. Once we've determined whether there are any other failures that we believe are caused by bugs in the compliance tool, I'll raise appropriate bug reports with the UPnP forum.


RE: State variables names in scpd - SiMet - 21-10-2015 09:34 AM

Hi Simon,

Do you have some information about this topic?