> -----Original Message-----
> From: MARK [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 11, 2002 11:57 AM
> To: Struts Developers List
> Subject: RE: [Resources] XMLMessageResources and Proposal
>
>
> Why use xml for the message resources in the first place?
> Using XMl doesnt add any inherent value. The properties file
> is fine, easy to use/read, and XML is way too wordy,
> constricting. Seems like its not advantageous to me, perhaps
> Im missing something.
Well, one reason is if you are using an translation service to create
localised message resources. TMX is the standard format for localised
message exchange, so that is likely to be what your translation service
wants to get from you, and wants to give you.
> There is already a tool that builds
> the application resources properties file from xml (Called
> Karapan, struts application generator).
You mean Karapan Sapi. I haven't looked at this tool yet, and didn't realise
it generated properties files. It doesn't seem to mention this on the web
site (although I may well have missed it).
--
Martin Cooper
>
> Regards,
> Mark
>
>
> Martin (and others)
> >>
> >> On a suggestion by Craig, I had a look at the commons resources
> >> XMLMessageResources. It appears (and I could be wrong) that this
> >> implementation expects a structure similar to this:
> >> (I couldn't find any samples or test data, so I just guessing
> >> by browsing
> >> the code)
> >>
> >> <messages>
> >> <message key="some.key">Some Value</message>
> >> </messages>
> >
> >Yep, that's it. Looks pretty lame, huh? ;-) Let me explain
> my thinking when
> >I wrote it, which might make it look a little less lame (I hope :).
> >
> >I figured that there were a few possible approaches to this.
> >
> >1) Define our own XML format.
> >2) Pick a standard format.
> >3) Somehow allow the use of an arbitrary format.
> >
> >My first inclination was to do (3), because that allows the
> most flexibility
> >for people to use whatever they already have, or to define
> whatever they
> >want, and then specify a mapping so that we could read it.
> However, at the
> >time, I hadn't a clue as to how to go about implementing
> such a thing. (But
> >see below.)
> >
> >My next thought was to go with (2), and I looked at TMX for a while.
> >However, TMX is a pretty complex format, and it wasn't at
> all clear to me
> >that it was (a) appropriate and (b) feasible to use that as
> the basis for
> >the kind of message resources we're talking about here. In
> case you're not
> >familiar with TMX, you'll find the scoop here:
> >
> >http://www.lisa.org/tmx/
> >
> >That left option (1). In implementing that, I decided to
> follow the KISS
> >principle, and create a minimal XML format that maps pretty
> directly to what
> >is done with property files. My thinking was that, with such a simple
> >format, it would be straightforward for anyone already using
> their own
> >format to write an XSLT stylesheet to convert their existing
> XML files into
> >the XMLMessageResources format, most likely to be run as
> part of their web
> >app build process.
> >
> >Some time ago, I sent a message out (to struts-user, I
> think) about what
> >people really wanted in an XML message resource
> implementation. The answers
> >that came back said we need to do option (3) above. As I
> said earlier, at
> >the time I wrote the current code, I had no clue how to do this.
> >
> >However, that was before the Digester's XML Rules package
> existed, and also
> >before Betwixt existed (or at least before I had any idea
> what it was). With
> >these tools, I now think we have a good chance at being able
> to create a
> >very flexible "use whatever XML format you like"
> implementation for XML
> >message resources.
> >
> >>
> >> or is it...
> >>
> >> <messages>
> >> <message key="some.key" value="Some Value"/>
> >> </messages>
> >>
> >>
> >> How do you handle special characters in the values? (<, >, ")
> >>
> >>
> >>
> >> [Proposal] (Sort of)
> >> Would it be feasible to allow an open structure?
> >> What I mean is....what about allowing a structure like this:
> >>
> >> <index>
> >> <heading en="MailReader Demonstration Application Options"
> >> fr="Options D'Application De Démonstration De
> MailReader"/>
> >> <logon en="Log on to the MailReader Demonstration Application"
> >> fr="Entrez à l'application de démonstration de
> >> MailReader"/>
> >> <registration en="Register with the MailReader
> >> Demonstration Application"
> >> fr="Inscription à l'application de démonstration
> >> de MailReader
> >> "/>
> >> <title en="MailReader Demonstration Application
> (Struts 1.1-dev)"
> >> fr="Application De Démonstration De MailReader
> >> (Struts 1.1-dev)
> >> "/>
> >> <tour en="A Walking Tour of the Example Application"
> >> fr="Une excursion de marche de l'application
> d'exemple"/>
> >> </index>
> >>
> >>
> >
> >Personally, I have always favoured keeping multiple
> translations in separate
> >XML files. This avoids issues related to different character
> encodings
> >required for different languages. However, I don't recall
> whether this
> >matches with TMX or not.
> >
> >> I have a feature list a mile long that I am working through, so I'm
> >> nowhere close to being finished.
> >>
> >> If I complete this, is it feasible to add it to sandbox
> >> resources or struts?
> >> If not, then I will drop it and work on other issues (pending
> >> Struts bugs).
> >
> >There was a brief discussion on whether or not we would try
> to migrate to
> >Commons Resources for Struts 1.1, but I don't recall the
> outcome, so I'll
> >need to go back and dig that up.
> >
> >--
> >Martin Cooper
> >
> >
> >>
> >>
> >>
> >> James Mitchell
> >> Software Engineer/Struts Evangelist
> >> http://www.open-tools.org
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >> For additional commands, e-mail:
> >> <mailto:[EMAIL PROTECTED]>
> >>
> >>
> >
> >
> >--
> >To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
