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
