Dear Developers, I've been listening in on the list conversations for a while and now I have a some questions about Data Forms and jabber:iq:register namespace. First off, I'm very familiar with these JEPs
JEP-0004: Data Forms JEP-0020: Feature Negotiation JEP-0068: Field Standardization for Data Forms JEP-0030: Service Discovery JEP-0050: Ad-Hoc Commands JEP-0060: Publish-Subscribe so feel free to reference these in your replies. I'm working on a research project to use XML communication for industrial instrumentation (voltmeters, oscilloscopes, function generators, temperature/pressure probes, high resolution CCD cameras, data acquisition cards, etc). There are numerous connectivity options for these field devices (RS-232/485, GPIB, Ethernet, Fiber, PCI/ISA register based) and countless protocols (simple text, modbus, VXI-11, SCPI, VISA, home grown, etc). My research project is looking to unify communication with all these disparate devices using XML. I'm looking at the state of Jabber and XMPP to determine if the functionality for all my instrumentation requirements can be implemented. So far, Jabber and XMPP look great! I've spent the last two months researching the situation, even coded up an extremely simple example that connected an old HP voltmeter to a chat room. These instruments have a command structure that maps well into Ad-Hoc Commands. Their parameter hierarchical structure maps into the Service Discovery node structure. Which brings me to my first question, I've having a little problem seeing the use of Service Discovery and Data Forms together. Using a recursive disco#items query, you might discover this oscilloscope node, 'Vertical/CH3/Scale' with a <feature var='value'>. Now I want to use a data form to allow modification of this var='value'. Question 1: Is it within the Jabber way to include a node attribute in the query tag for a data form registration query? Here, I'm modifying JEP-0004 example 1. Example 1. Send: Asking the Component for the registration requirements <iq type='get' to='scope1.jabber.org' id='data1'> <query xmlns='jabber:iq:register' node='Vertical/CH1/Scale'/> </iq> Assuming yes. Question 2: Did the Jabber architects intend to map 'service discovery node feature vars' to 'data form field vars'? And now the big question. Question 3: My application's use of forms will be extensive but data gathering will have little in common with the jabber:iq:register namespace. I don't see a mapping of JEP-0077 In-Band Registration 13.3 Field Standardization fields to my devices. If I use the approach of JEP-0004's Data Forms, all my data will use the <x/> tag with the jabber:x:data namespace. So my question is, should I a. live with <x/> extention approach of Data Forms and the jabber:iq:register namespace b. define a new namespace to use instead jabber:iq:register for IQ queries c. use the jabber:x:data as the new namespace for IQ queries d. wait for new namespace to be devised that generalizes data form queries away from jabber:iq:register Please comment on Q1, Q2 and the pros and cons of Q3's approaches a, b, c and d. I appreciate your time for reading this posting and any comments you have. Thanks, Craig -- ------------------------------------------------------------ Dr. Craig Hollabaugh, [EMAIL PROTECTED] Author of Embedded Linux: Hardware, Software and Interfacing www.embeddedlinuxinterfacing.com _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
