On Wed, Nov 14, 2012 at 11:26 PM, Christophe Dupriez <dupr...@destin.be> wrote:
> Dear Ichiro,
>
> I take your point that what I propose does not fit in the JSPWiki "spirit".
Hi Christophe,
Honestly, I don't suggest that anyone is in a place to dictate what is
or isn't the spirit of the project -- except perhaps its founder -- but I
think we all have to be mindful of the boundary of what is appropriate
to the project and what are simply our own requirements. And it sounds
like both of us have on occasion extended the feature set of JSPWiki
towards our own ends, as required by specific project requirements.
It's to JSPWiki's credit that it is relatively easy to extend in this
manner (and why on occasion I bemoan its rising complexity).
> The need is to associate parts of a Wiki Page to an "entity", something
> pointed by an URL with data associated with it, data which needs to be
> formatted for display.
>
> From the previous discussion, it is now clear to me that the WikiPage author
> do not need to enter data there but should obtain the desired display by
> just making the reference.
Yes, this seems to be a somewhat common requirement, i.e., the ability to
pull records from a database.
I suppose the only thing I'm suggesting is the idea that *everything*, the
wiki pages, all links, and all referenced entities, all exist in the *same*
database. A radical concept perhaps, and probably not a requirement
for JSPWiki, just a blue sky proposal.
> Let's forget JSP and concentrate on a Plugin like the others: make a generic
> Plugin that can be derived for individual needs allowing to write:
> * [{DLAPA rec="12345"}]
> * [{DLAPA rec="67890"}]
> ...
> This would return WikiMarkup (and not HTML) displaying record 12345 and
> 67890 from source application named "DL" formatted in APA format. For
> another source or another format, another plugin would be defined by a
> programmer.
>
> The plugin would therefore be responsible to access the application, get the
> data and format it in WikiMarkup.
Actually, the contract with a WikiPlugin is that it should return XHTML
markup, since the point in the process workflow in which the plugin is
called is during rendition. If a plugin returned WikiMarkup it would be
displayed as such on the output, not rendered.
That aside, yes, in general a plugin of the form you outline is no issue.
> One generic plugin could be to use SPARQL servers as source, parameterized
> in some configuration files. SPARQL field names could be inserted in some
> WikiMarkup template. Simple and efficient? Example:
> [{SPARQL config="dbpediaCountriesPopulation" param="Belgium"}]
> This would use a configuration "dbpediaCountriesPopulation" to access
> DBPedia and return a WikiMarkup table of Belgium Population statistics
Again, no issue except the plugin would return an XHTML table markup
showing the table of Belgian population statistics.
> Excuse me to not share your enthusiasm for STAX: it is essential for big
> documents (I use it for that: RDF to XML transformations...) but WikiPages
> are not that long and templates are hard enough to keep them unconstrained.
> Anyway the main problem today is to DEFINE the process to translate
> (normalize) XHTML into WikiMarkup. XSLT is certainly a way to experiment
> (and share results). Let's start something like bringing together test
> cases?
StAX is not for big documents, it's simply the streaming XML API used as a
replacement for SAX. The real comparison here is between DOM and Axiom, or
perhaps DOM and another potential replacement such as JDOM or XOM. Anyone
who's had to work with the DOM knows how much of a pain it is, and any of
the replacements are significant improvements. Having a great deal of
experience with pretty much all of them I would at this point recommend
Axiom, for both stability, ease of use by developers, industry support
(it's the OM used by Apache Axis web services) and certainly performance.
So if anyone were to go to the trouble of rewriting the XHTML to WikiMarkup
tools, they would either use Axiom or XSLT. Perhaps we can leave it at that,
as someone would have to step up to the plate to actually do that work. I
can only make recommendations.
> Thanks for the good discussion and have a very nice day!
Likewise, much appreciated.
Ichiro
