Dear Ichiro,
I already modified extensively XHtmlElementToWikiTranslator.java to
provide a good coverage of the needs for CK editor
(i.e. I solved all users complaints)
But:
a) it was "trial and error" based
b) it does not support insertion of Plugins correctly
I would suggest to use your approach (XSLT) if it helps the community to
contribute.
Meanwhile, would it be possible to open a branch for the code I already
have to support CK editor?
Who is interested by CK editor???
I am more than ever since I saw with father, 79 years old, despaired to
contribute to Wikipedia, obliged to learn WikiMarkup, when all his
contributions area already redacted in WordPerfect (or Word or whatsoever).
For the support of plugins, it is way better that, as you explain, they
produce XHTML.
This means that some plugins, inheriting from a SNIP plugin to create,
could:
1) collect data from any database or SparQL service
2) format it in XHTML including HTML5 itemscope, itemprop
The insertion of such plugins should be supported in the CK editor...
Thanks a lot for this discussion which clarifies fully the way to go for
me and I hope some manifestation of interest by the community for CK
editing.
I can host an application in my server where one could paste XHTML,
process it using an XSLT and look at the generated WikiMarkup (source
as-is and interpreted by JSPWiki)
I would put that in ASKOSI wiki:
http://www.destin-informatique.com/ASKOSI/Wiki.jsp?page=CK-JSPWiki
Would this be suitable for community work on this topic ???
Have a nice day!
Christophe
Le 15/11/2012 05:07, Ichiro Furusato a écrit :
It occurs to me I didn't actually answer you principal question...
On Wed, Nov 14, 2012 at 11:26 PM, Christophe Dupriez <dupr...@destin.be> wrote:
[...]
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?
I think if you were to look at an XSLT approach it's not quite
so bad. Whereas in XHtmlElementToWikiTranslator.java you see
else if( n.equals( "h2" ) )
{
m_out.print( "\n!!! " );
print( e );
m_out.println();
}
basically the pattern in XSLT would be something akin to:
<xsl:template name="h2">
<xsl:text>
!!! </xsl:text>
<xsl:apply-templates/>
</xsl:template>
where we match via an XPath and output WikiMarkup. It would also
be a lot more reliable. The big question might seem to be whether
or not the input XHTML is truly well-formed XML or not. By definition
in XHTML it *must* be but of course in the real world that might
not be the case, and the XSLT wouldn't accept non-WF XML. But I'm
assuming that given the input to XHtmlElementToWikiTranslator.java
is a DOM Document we're already past that hurdle.
So what we'd need to do to define the transformation would be to
have a set of XPaths (particular markup patterns in XHTML) and what
each XPath would generate in WikiMarkup. If we were to go to that
trouble the XSLT solution would be almost a byproduct of that work.
Ichiro
