Howdy LLRP Toolkit folks,
Paul D. recently posted a detailed
description of the LTK XML files.
I'd like to offer this short summary
that explains the motivations.
The LLRP Specification (EPCg) describes
LLRP in two ways:
1) The "abstract" protocol that explains
organization and semantics
2) The "binary" protocol that, through diagrams,
describes the over-the-write encoding.
The spec does not provide two things I
think are important:
1) A machine processable description of the
protocol such that formal analysis (like
code generators) can be done
2) A convention for textual representation of
LLRP messages, parameters, etc, independent
of any particular programming language,
environment, or paradigm, or any particular
application.
When we looked for a text format to meet those
two needs, XML was the obvious (but not the only)
answer. There is tremendous availability of XML
technologies, especially XML-aware text editors.
XML has "instance" document that follow a particular
"schema" (rules for the instance). That the schema
are also represented as XML can be a little confusing
at first, but one gets used to it. Files containing
XML instances typically have suffix ".xml". Schema
files typically have suffix ".xsd".
The XML files in the tool kit are.....
Definitions/llrpdef.xsd
The schema for XML instances that describe the
over-the-wire protocol.
Definitions/Core/llrp-1x0-def.xml
An XML instance that conforms to llrpdef.xsd.
This describes the "core" LLRP protocol per
the EPCg LLRP spec 1.0. It contains sufficient
details for software to encode and decode
over-the-wire LLRP.
Definitions/Core/llrp-1x0.xsd
The XML schema for XML instances that describe
LLRP messages. These instances are human readable
and, esp with the schema support, allow an XML-aware
editor to aid craft LLRP messages.
An example....
Suppose I prepare an XML document containing
this simple LLRP message (resets the reader config)
<SET_READER_CONFIG>
<ResetToFactoryDefaults>True</ResetToFactoryDefaults>
</SET_READER_CONFIG>
This *instance* of an LLRP message conforms to the
Definitions/Core/llrp-1x0.xsd schema.
So, how does that get turned into a "binary",
over-the-wire LLRP message?
That's the function of the LTK implementations.
Using the llrp-1x0-def.xml description, an LTK
implementation prepares encoder/decoders.
These translate between XML instances in
"external" form (binary, XML) and an internal form.
Some implementations, like LTKPerl, use run-time
encoders/decoders guided by llrp-1x0-def.xml.
Their internal representations might be
associative arrays (hashes).
Some implementations, like LTKC, LTKCPP, and LTKJava,
use generators to produce encoders/decoders. They
use native objects as the internal representation.
In any case, a properly implemented LTK can
translate an XML message from the XML text form
to the binary form and back again. The binary
form conforms to the EPCg LLRP spec. The XML form
conforms to Definitions/Core/llrp-1x0.xsd schema.
My immediate intention for the above is to
foster discussion. Hopefully that will aid
refining the documents about LLRP uses of XML.
Those documents will eventually be placed on the Wiki.
Regards,
-gww
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
