(Written in between afternoon and evening festivities)
In terms of purely "byte stream" communication, I do not think it is that
important to merge the two XML "class description" files. In fact, it is
probably good to have both flavors of code generation in order to test one
against the other and see if any discrepancies result in the byte streams. And
if we need to make minor tweaks to the class descriptions, tweaking two files
is not that much harder than tweaking one.
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.
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.
--Joe
----- Original Message -----
From: Gordon Waidhofer <[EMAIL PROTECTED]>
Date: Tuesday, July 3, 2007 6:37 pm
Subject: Interoperable XML for LLRP messages
To: LLRP Toolkit Development List <[email protected]>
Cc: "Joseph E. Hoag" <[EMAIL PROTECTED]>
>
>
> Howdy LLRP Tool Kit (LTK) folks,
>
>
>
> I believe one of the most important tenants of the LTK is that
>
> all API implementations - across programming languages
>
> and platforms - support XML of LLRP messages that can be exchanged.
>
> This opens the door for many conveniences such as communicating
>
> best practices and furnishing details with support requests.
>
>
>
> The names for XML elements, enumerated values, etc, are the
>
> tricky part. It follows that an API implementation is likely to use
>
> function and class/structure names derived from those element names.
>
>
>
> There are (so far) two machine processable descriptions of LLRP.
>
> The names for things differ. Maybe not much, but enough.
>
> Converging descriptions means that names are going to change
>
> and it follows that programming names may change, too.
>
> They don't have to, of course, but it seems counterproductive
>
> to introduce features into descriptions to preserve differing
>
> names for things.
>
>
>
> Before we launch into discussions about how to converge,
>
> let's see if it matters.
>
>
>
> Are there opinions on consistent, exchangeable XML descriptions
>
> of LLRP messages? Is this important to folks? Unimportant?
>
>
>
> Regards,
>
> -gww
>
>
>
>
-------------------------------------------------------------------------
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
