The updated VTS (3.6.2) wants object types named as, eg, "binary-input" in most places (protocol-object-types-supported:, object-list:, object-type:) but wants "Binary Input" for Standard Object-Types Supported
Is there a standard for EPICS that requires this? Should I modify VTS to take the "dashed" object type names? Or do we want to keep it like this?
If "modify VTS", should I make it less strict so that it accepts both ways for Standard Object-Types Supported?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The EPICS syntax is defined in clause 4 of the BACnet test standard (ASHRAE Standard 135.1-YYYY), and there is an example EPICS file in Annex A.
We should not change VTS in a way that would mean that EPICS files that conform to the BACnet test standard would no longer be accepted. Making VTS less strict would probably be o.k.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Clause 4.5.4 and Annex A of 135.1-2013 uses spaces in object types under “Standard Object Types Supported”.
Clause 4.4 (i) says that enumerations use underscore or dash. 4.4 (l) shows (but doesn’t explicitly require) the object-type portions of an object-id using dashes.
That is what VTS 3.6.2 matches.
Extending “Standard Object Types Supported” to ALLOW dashes or underbars is probably reasonable.
If you want to make any significant changes to EPICS parsing, please let me know: I have been working intermittently on a pretty significant re-write of Vtsapi32.cpp to make the parsing more robust, to accept tags required by 135.1, etc.
I have been waiting for Duffy to send me some sample EPICS that I can test with to verify backward compatibility before I check it in.
(Duffy was going to anonymize the EPICS. If anyone reading this that has an EPICS acceptable to BTL that they can send me, I would appreciate it)
I should also note that there are a bunch of places where 135.1 Annex A DOES NOT follow the rules given in 135.1 clause 4.4. The file allTestEpics.tpi included with VTS has a third set of rules. In some cases VTS won’t parse either 135.1 version, but DOES include legacy formats that apparently pre-date 135.1 (some of which are used in allTestEpics.txt)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From ANSI/ASHRAE Standard 135.1-2009, Clause 4.4.i:
"enumerated values are represented as named, rather than numeric, values. Enumeration names are case insensitive so that X'41' through X'5A' are equivalent to X'61' through X'7A'. The underscore (X'5F') and dash (X'2D') are considered equivalent in enumeration names. Proprietary values are shown as a named text with no whitespace and ending in a non-negative decimal numeric. Each must start with the word "proprietary": Object_Type, proprietary-object-type-653"
There is currently no mention of space (X'20') being equivalent to underscore (X'5F') and dash (X'2D') in the named enumerations. I wonder why Standard Object Types Supported section used them in the example EPICS in the standard unless it was by mistake? I would imagine that the Standard Object Types Supported section of the EPICS is much harder to parse due to that deviation.
It should be possible to allow the correct parsing with dashes and underscore, and still allow the spaces, as Jim suggested, so that is what I would recommend for now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The EPICS format is rather curiously ad-hoc. The first few sections, including Standard Object Types Supported, Data Link Layer Options, Character Sets, etc. are all kind of "Englishy": English words, with informal syntax (no commas to separate items, etc)
Then the "List of Objects in Test Device" uses a more formal syntax, more or less per 4.4.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The updated VTS (3.6.2) wants object types named as, eg, "binary-input" in most places (protocol-object-types-supported:, object-list:, object-type:) but wants "Binary Input" for Standard Object-Types Supported
Is there a standard for EPICS that requires this? Should I modify VTS to take the "dashed" object type names? Or do we want to keep it like this?
If "modify VTS", should I make it less strict so that it accepts both ways for Standard Object-Types Supported?
The EPICS syntax is defined in clause 4 of the BACnet test standard (ASHRAE Standard 135.1-YYYY), and there is an example EPICS file in Annex A.
We should not change VTS in a way that would mean that EPICS files that conform to the BACnet test standard would no longer be accepted. Making VTS less strict would probably be o.k.
Clause 4.5.4 and Annex A of 135.1-2013 uses spaces in object types under “Standard Object Types Supported”.
Clause 4.4 (i) says that enumerations use underscore or dash. 4.4 (l) shows (but doesn’t explicitly require) the object-type portions of an object-id using dashes.
That is what VTS 3.6.2 matches.
Extending “Standard Object Types Supported” to ALLOW dashes or underbars is probably reasonable.
If you want to make any significant changes to EPICS parsing, please let me know: I have been working intermittently on a pretty significant re-write of Vtsapi32.cpp to make the parsing more robust, to accept tags required by 135.1, etc.
I have been waiting for Duffy to send me some sample EPICS that I can test with to verify backward compatibility before I check it in.
(Duffy was going to anonymize the EPICS. If anyone reading this that has an EPICS acceptable to BTL that they can send me, I would appreciate it)
I should also note that there are a bunch of places where 135.1 Annex A DOES NOT follow the rules given in 135.1 clause 4.4. The file allTestEpics.tpi included with VTS has a third set of rules. In some cases VTS won’t parse either 135.1 version, but DOES include legacy formats that apparently pre-date 135.1 (some of which are used in allTestEpics.txt)
From ANSI/ASHRAE Standard 135.1-2009, Clause 4.4.i:
"enumerated values are represented as named, rather than numeric, values. Enumeration names are case insensitive so that X'41' through X'5A' are equivalent to X'61' through X'7A'. The underscore (X'5F') and dash (X'2D') are considered equivalent in enumeration names. Proprietary values are shown as a named text with no whitespace and ending in a non-negative decimal numeric. Each must start with the word "proprietary": Object_Type, proprietary-object-type-653"
There is currently no mention of space (X'20') being equivalent to underscore (X'5F') and dash (X'2D') in the named enumerations. I wonder why Standard Object Types Supported section used them in the example EPICS in the standard unless it was by mistake? I would imagine that the Standard Object Types Supported section of the EPICS is much harder to parse due to that deviation.
It should be possible to allow the correct parsing with dashes and underscore, and still allow the spaces, as Jim suggested, so that is what I would recommend for now.
The EPICS format is rather curiously ad-hoc. The first few sections, including Standard Object Types Supported, Data Link Layer Options, Character Sets, etc. are all kind of "Englishy": English words, with informal syntax (no commas to separate items, etc)
Then the "List of Objects in Test Device" uses a more formal syntax, more or less per 4.4.