(I appologize if this is a dup. My email is behaving strangely). > Maybe I'm missing the point. Are you talking about > implementing some sort of XML-based LLRP standard > solely for use in debugging and testing?
Once one has an XML way to communicate LLRP messages, even just between humans, it's impossible to go back. John is working on a perl LLRP toolkit. It uses XML for its API data structures. It is so so so so easy to put the XML of an LLRP message into a perl script and send binary to a reader. Would perl be used solely for debugging and testing? Would we have multiple instances of a perl tool kit if there are multiple definitions of LLRP XML? I like having a way to communicate between humans LLRP specifics. This isn't just debugging and testing. Suppose somebody asks, "How do we get LLRP to generate a tag report every 15 seconds?" The answer could be: <?xml version="1.0" encoding="UTF-8"?> <ADD_ROSPEC MessageID="10" xmlns="LLRP" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="LLRP LLRP.xsd "> <ROSpec> <ROSpecID>1</ROSpecID> <Priority>0</Priority> <CurrentState>Disabled</CurrentState> <ROBoundarySpec> <ROSpecStartTrigger> <ROSpecStartTriggerType>Immediate</ROSpecStartTriggerType> </ROSpecStartTrigger> <ROSpecStopTrigger> <ROSpecStopTriggerType>Null</ROSpecStopTriggerType> <DurationTriggerValue>0</DurationTriggerValue> </ROSpecStopTrigger> </ROBoundarySpec> <AISpec> <AntennaIDs>0</AntennaIDs> <AISpecStopTrigger> <AISpecStopTriggerType>Duration</AISpecStopTriggerType> <DurationTrigger>15000</DurationTrigger> </AISpecStopTrigger> <InventoryParameterSpec> <InventoryParameterSpecID>1234</InventoryParameterSpecID> <ProtocolID>EPCGlobalClass1Gen2</ProtocolID> <AntennaConfiguration> <AntennaID>0</AntennaID> <C1G2InventoryCommand> <TagInventoryStateAware>false</TagInventoryStateAware> <C1G2RFControl> <ModeIndex>2</ModeIndex> <Tari>0</Tari> </C1G2RFControl> <C1G2SingulationControl> <Session>2</Session> <TagPopulation>40</TagPopulation> <TagTransitTime>0</TagTransitTime> </C1G2SingulationControl> </C1G2InventoryCommand> </AntennaConfiguration> </InventoryParameterSpec> </AISpec> <ROReportSpec> <ROReportTrigger>Upon_N_Tags_Or_End_Of_AISpec</ROReportTrigger> <N>0</N> <TagReportContentSelector> <EnableROSpecID>false</EnableROSpecID> <EnableSpecIndex>false</EnableSpecIndex> <EnableInventoryParameterSpecID>false</EnableInventoryParameterSpecID> <EnableAntennaID>true</EnableAntennaID> <EnableChannelIndex>false</EnableChannelIndex> <EnablePeakRSSI>true</EnablePeakRSSI> <EnableFirstSeenTimestamp>true</EnableFirstSeenTimestamp> <EnableLastSeenTimestamp>true</EnableLastSeenTimestamp> <EnableTagSeenCount>true</EnableTagSeenCount> <EnableAccessSpecID>false</EnableAccessSpecID> </TagReportContentSelector> </ROReportSpec> </ROSpec> </ADD_ROSPEC> It is unambiguous. It is machine readable. It is human readable. It is navigable with an XML editor. It can be validated against an XML schema. It is programming language generic. With tools like the perl toolkit and toolkit implementations that grok the XML, it is executable. I much prefer this to vague descriptions or programming language code fragments. It doesn't much help me to get a C++ code fragment if I'm using Java, and vice versa. Would others please chime in. Is having XML to communicate and/or use LLRP important? Unimportant? Why? As I wrote in my original post, I'd like to better understand how necessary convergence is. As Joe wrote, if we converge on an XML description we likely have to converge the toolkits for the various languages. Convergence will cause pain. Does it matter to folks? Are you willing to bear your share of the pain for convergence? Or are you more willing to bear your share of the pain for divergence? Or.... what? There are no right or wrong answers and this point. Perspectives are helpful. This reply is just my long winded way of responding to Joe's question: Is XML just for debugging and testing? Short answer: No, having had the benefit of LLRP XML. Regards, -gww -----Original Message----- From: Joseph E. Hoag [mailto:[EMAIL PROTECTED] Sent: Thu 7/5/2007 5:33 AM To: John R. Hogerhuis Cc: LLRP Toolkit Development List; Gordon Waidhofer Subject: Re: [ltk-d] Interoperable XML for LLRP messages I think that communicating LLRP through XML is a really good idea in theory. It makes debugging and testing a lot easier. However, unless you can make it a standard that all LLRP-capable readers support, then it is not worth much. Speaking as one who will participate in the writing of the LLRP client for TagCentric, I would only implement "byte stream" LLRP, because I know that *all* LLRP-capable readers support byte stream LLRP. In my mind, XML-based LLRP messages would *only* be used for debugging and testing. No one would use XML-based LLRP for their primary messaging mechanism because it is not a standard. Maybe I'm missing the point. Are you talking about implementing some sort of XML-based LLRP standard solely for use in debugging and testing? --Joe ----- Original Message ----- From: "John R. Hogerhuis" <[EMAIL PROTECTED]> Date: Thursday, July 5, 2007 12:45 am Subject: Re: [ltk-d] Interoperable XML for LLRP messages To: LLRP Toolkit Development List <[email protected]>, "Joseph E. Hoag" <[EMAIL PROTECTED]> Cc: Gordon Waidhofer <[EMAIL PROTECTED]> > On 7/4/07, Joseph E. Hoag <[EMAIL PROTECTED]> wrote: > > > > > > > > However, if we decide that human-readable communications (i.e., XML > > messages) need to be supported (in addition to byte streams), > then it will > > probably become important to get align class names and parameter > names> between languages. This is accomplished more easily if all > languages> generate off of a single class description file. > > > > Let's be realistic, though -- tweaking class names and method > > names/signatures in a library is more or less the same as > replacing the > > entire library in terms of the pain that it will cause > developers. If the > > Java library is tweaked to look like the C++ library (in terms of > > class/method naming), then it essentially becomes a new library, > and users > > (like TagCentric and Rifidi) will need to spend considerable > time re-writing > > to conform to the new library. > > > > I am not sure I agree with that... the actual names used when binding > to a library is not hard to change. It is much harder to switch > libraries altogether, since with a new library comes a different class > hierarchy, set of interfaces, memory management strategies, > synchronization issues, etc. Changing names is a search and replace > operation. Changing libraries has an aspect of design to it. > > I think it would be a mistake for the Java library to be forced to > "look like" the C++ library. Certainly the Perl library to be > contributed doesn't look anything like the Java or C++ library. Each > language is different so naturally the APIs will be different. That > said, the underlying concepts are invariant, since all these APIs end > up talking binary LLRP. So there can be some level of commonality. > Probably the names of enumerations messages, parameters and fields is > about all we can hope for. Even then, I can imagine issues of > camel-casing vs. lowercase, etc. problems where the culture for a > particular language will dictate. When that cannot be automatically > inferred from standard names, we could conceivably provide > alternatives in the schema. > > > Do we really need to develop a de-facto XML LLRP messaging > standard (with > > standard element names and formats) to go along with the byte- > stream LLRP > > messaging standard? This is debatable, and may cause more > problems than it > > solves. But if we decide that the answer is yes, then we > probably want to > > merge the class description files sooner rather than later. > > > > Having been using this format for the last several months, I find it > indispensible. Having a textual represenation of LLRP, along with > XPath, and some code to manage the TCP link, has served us like a > domain-specific programming language tailored to LLRP. And the social > aspect of being able to communicate about LLRP in an unambigous is > hard to overstate. > > What kinds of issues do you foresee with the abstract schema? > > -- John. > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
