Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
State variables names in scpd
15-06-2015, 12:18 PM
Post: #1
State variables names in scpd
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.
Find all posts by this user
15-06-2015, 12:26 PM
Post: #2
RE: State variables names in scpd
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?
Find all posts by this user
15-06-2015, 01:32 PM
Post: #3
RE: State variables names in scpd
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.
Find all posts by this user
16-06-2015, 04:47 PM
Post: #4
RE: State variables names in scpd
(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.
Find all posts by this user
18-06-2015, 10:27 AM
Post: #5
RE: State variables names in scpd
Could you provide me some information about this spec which you think conforms to current behaviour?
Find all posts by this user
18-06-2015, 01:17 PM
Post: #6
RE: State variables names in scpd
(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.
Find all posts by this user
19-06-2015, 12:47 PM
Post: #7
RE: State variables names in scpd
(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."
Find all posts by this user
19-06-2015, 12:51 PM
Post: #8
RE: State variables names in scpd
(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.
Find all posts by this user
21-10-2015, 09:34 AM
Post: #9
RE: State variables names in scpd
Hi Simon,

Do you have some information about this topic?
Find all posts by this user


Forum Jump: