Again, I'm not debating the "coolness" of messaging via XML instead of byte streams. You're preaching to the choir on that one. But that's not really my issue. If LLRP via XML is not an industry standard, then why would an LLRP client use it for communication? Smart LLRP client writers will stick to byte stream LLRP, because that's the only thing that LLRP readers are guaranteed to support.
Unless, of course, you manage to make LLRP-via-XML an industry standard... --Joe ----- Original Message ----- From: Gordon Waidhofer <[EMAIL PROTECTED]> Date: Thursday, July 5, 2007 10:15 am Subject: RE: [ltk-d] Interoperable XML for LLRP messages To: "Joseph E. Hoag" <[EMAIL PROTECTED]>, "John R. Hogerhuis" <[EMAIL PROTECTED]> Cc: LLRP Toolkit Development List <[email protected]> > > (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 > <AISpecStopTrigger> > <AISpecStopTriggerType>Duration > <DurationTrigger>15000</DurationTrigger> > > <InventoryParameterSpec> > <InventoryParameterSpecID>1234</InventoryParameterSpecID> > <ProtocolID>EPCGlobalClass1Gen2</ProtocolID> > <AntennaConfiguration> > <AntennaID>0 > <C1G2InventoryCommand> > <TagInventoryStateAware>false</TagInventoryStateAware> > <C1G2RFControl> > <ModeIndex>2</ModeIndex> > <Tari>0</Tari> > </C1G2RFControl> > <C1G2SingulationControl> > <Session>2</Session> > <TagPopulation>40</TagPopulation> > <TagTransitTime>0</TagTransitTime> > </C1G2SingulationControl> > </C1G2InventoryCommand> > > </InventoryParameterSpec> > > <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> > > > 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 <llrp-toolkit- > [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
