> > We also noticed that there seem to be different approaches to code
> > generation: XSLT for C++, Java plus manual "tweaks". We are
> currently
> > looking into using Apache Velocity.
> >
>
> XSLT is common ground when dealing with generating text or
> XML from XML. Basing the code generators on Java would mean
> not having a ready solution and example for, say, generating
> C# code. So any examples we create for Java would not be very
> reworkable for C# folks that know nothing about Java.
>
> I don't know anything about Velocity. What kind of facilities
> does Apache Velocity offer vs. XSLT that have proven useful to you?
>
My (limited) experience with XSLT for code generation is that transparency
tends to suffer because the output code is mixed with parsing logic ("No
seperation of concerns"). There is also no way to visualize how the output
code will look like. Maintenance of the XSLT code over the project lifecycle
thus tends to become more difficult.
We are currently looking into Apache Velocity because of its template
strategy, where the (XML) parsing code is separate from the output
generation code. One of the benefits of this separation is that the parsing
code can be reused for different implementations (say java and c#).
We just started with the implementation so I cannot really say how well the
template approach works for LLRP code generation. I'll post an update to the
mailing list soon.
John, you mentioned work on a perl implementation. Are you using the perl
template toolkit (http://www.template-toolkit.org/) ?
In our opinion, one thing that should be avoided is code generators which
require manual adjustment after some of the code is generated. The problem
with that is that developers start making changes to the generated code
instead of the code generator. This makes future use of the code generation
tricky if not impossible. One trick to avoid this problem is never to check
the generated source into the version control system.
> It doesn't seem as critical that we standardize on code
> generation techniques as it is to standardize on the binary
> and abstract schemata. If we don't standardize on the binary
> and abstract schemata, I don't think we have a cohesive
> project. If we don't standardize on code generators we lose
> out on some efficiencies but we still have a cohesive project.
I agree.
- Christian
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of John R. Hogerhuis
> Sent: Mittwoch, 11. Juli 2007 20:05
> To: LLRP Toolkit Development List
> Subject: Re: [ltk-d] XML LLRP description
>
> Hi Christian,
>
> On 7/11/07, Christian Floerkemeier <[EMAIL PROTECTED]> wrote:
> >
> > At the Auto-ID Labs at MIT and ETH Zurich (www.accada.org)
> we started
> > work on a Java implementation that we would possibly like
> to donate to
> > the llrp-toolkit project.
> >
>
> Welcome to the list :-)
>
> > We were a bit surprised that there are now two different xml
> > descriptions of the LLRP protocol (one in the CVS commons
> folder and
> > one in the JAVA folder). Wasn't the goal of the XML machine
> > processable descriptions discussed previously to have a
> common way to
> > capture vendor extensions for all different implementations of the
> > LLRP toolkit (JAVA, C#, C++, Perl, etc.)? Don't multiple different
> > formats to describe LLRP and future vendor extensions
> defeat this purpose?
> >
>
> Yes. The Java library was added recently. It is a valuable
> contribution since some folks on the list are already using it.
> However I personally worry that it is unmaintained since no
> one on the list seems willing to commit to moving it to the
> common binary schema.
>
> > We are clearly in favour of having a single machine
> processable description.
> >
>
> Yep.
>
> > We did a quick comparison of the two XML description
> languages and we
> > like the one in the commons folder better for the following reasons:
> >
> > - there is an XSD schema available to validate the XML instance
> > - the XML description has references to the LLRP spec which we find
> > very useful
> > - the XML description distinguishes between unsigned and
> signed types
> > - the message names are in the LLRP format and not in Java notation
> > - there is support for vendor extensions
> >
>
> I'll underscore that it is critical that the schemata be as
> language independent as possible.
>
> > Since we are new to the project, we are just wondering what other
> > developers are thinking about the two XML description languages. We
> > noticed that there were previous emails on the mailing list, but we
> > are not sure whether someone had looked into the
> differences among the two xml descriptions.
> >
>
> I don't have an opinion on the Java library binary schema (I
> use schema here in the general sense) other than that it must
> eventually be based on LTK common schema. That said I don't
> think the common schema is fixed in stone at all.
>
> > We also noticed that there seem to be different approaches to code
> > generation: XSLT for C++, Java plus manual "tweaks". We are
> currently
> > looking into using Apache Velocity.
> >
>
> XSLT is common ground when dealing with generating text or
> XML from XML. Basing the code generators on Java would mean
> not having a ready solution and example for, say, generating
> C# code. So any examples we create for Java would not be very
> reworkable for C# folks that know nothing about Java.
>
> I don't know anything about Velocity. What kind of facilities
> does Apache Velocity offer vs. XSLT that have proven useful to you?
>
> It doesn't seem as critical that we standardize on code
> generation techniques as it is to standardize on the binary
> and abstract schemata. If we don't standardize on the binary
> and abstract schemata, I don't think we have a cohesive
> project. If we don't standardize on code generators we lose
> out on some efficiencies but we still have a cohesive project.
>
> -- 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
>
-------------------------------------------------------------------------
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
