Menu

displayName meta data

Standard
2014-02-18
2014-02-25
  • Carl Neilson

    Carl Neilson - 2014-02-18

    Clauses XX.36.5 and XX.36.6, includes the following text:

    The 'displayName' metadata for the device collection, for all locales, shall be the Object_Name property of the ... object without modification.

    Clause YY.4.9 includes the following:

    This optional metadata, of type String, provides a brief human-readable text to associate with the value of a data item.

    Do clauses XX.36.5 & .6 require that the displayName metadata be present on those data elements, or do they just specify the value when displayName is present?


    [cid:image001.png@01CF2C01.7C7FE660]Carl Neilson, Project Manager
    Delta Controls Inc.
    deltacontrols.comhttp://deltacontrols.com/

    cneilson@deltacontrols.comcneilson@deltacontrols.com
    direct: +1.604.575.5913
    mobile: +1.250.889.0000

    P Please consider the environment before printing this e-mail.
    This email message is directed in confidence solely to whom it is addressed. If you are not the intended recipient, you may not use or disclose any information contained here. If you received this email message in error, please reply to the sender immediately and delete the message along with any associated attachments. While every effort is made to ensure safe transmissions, it is still recommended that you scan any attachments for viruses.

     
    • Dave Robin

      Dave Robin - 2014-02-24

      Even though 'displayName' is generally optional, I think the intention of saying "shall" in those clauses was to mandate usable display names for the /.bacnet tree. Consider the user browsing the tree with a very simple discovery/enterprise/reporting tool that doesn't fully understand BACnet's structures. When browsing to a device at "/.bacnet/{scope}/1234" the tool wouldn't know that it has to find/descend to the Device object and then to the Object_Name property to get something other then "1234" to display to the user.

      This mandate for usable human display names extends to property and data field level as well. Yes, this is "raising the bar" for the server device, but I think it's really important for Web Services flavor of BACnet to be a much richer self-documenting experience for clients, and much less "numbery", than the binary version. So servers should help out the poor UI and give it something meaningful to display.

       
      • Carl Neilson

        Carl Neilson - 2014-02-25

        So we need to update those clauses to be clear that displayName shall be present.

        From: Dave Robin [mailto:daverobin@users.sf.net]
        Sent: Monday, February 24, 2014 3:16 PM
        To: [ampii:discussion]
        Subject: [ampii:discussion] Re: displayName meta data

        Even though 'displayName' is generally optional, I think the intention of saying "shall" in those clauses was to mandate usable display names for the /.bacnet tree. Consider the user browsing the tree with a very simple discovery/enterprise/reporting tool that doesn't fully understand BACnet's structures. When browsing to a device at "/.bacnet/{scope}/1234" the tool wouldn't know that it has to find/descend to the Device object and then to the Object_Name property to get something other then "1234" to display to the user.

        This mandate for usable human display names extends to property and data field level as well. Yes, this is "raising the bar" for the server device, but I think it's really important for Web Services flavor of BACnet to be a much richer self-documenting experience for clients, and much less "numbery", than the binary version. So servers should help out the poor UI and give it something meaningful to display.


        displayName meta datahttps://sourceforge.net/p/ampii/discussion/standard/thread/a71b76af/?limit=25#8658/f07f


        Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/ampii/discussion/standard/

        To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

         

Log in to post a comment.

MongoDB Logo MongoDB