One option here is to get serious about the 'post processing' stage of
parsoid. The goal was to have a stripped down HTML-based
representation for MW content. But many applications (kwix, pdf
rendering, etc) want some additional "sugar" in the HTML. They would
like, say, more precise link types, or alt and title tags on images,
or redlink information. I believe gwicke's original plan was to have
a post processing pipeline where this could be added.
Perhaps some of that postprocessing could optionally take place within
the parsoid codebase. If you requested "elaborated html" from
parsoid, it could go through and add some extra attributes and rel
types. Would that sort of design satisfy your needs, Emmanuel (and
allow us to remove the rel attribute in the core representation)?
--scott
On Wed, Jan 8, 2014 at 5:36 PM, Emmanuel Engelhart <kelson(a)kiwix.org> wrote:
Le 08/01/2014 23:32, C. Scott Ananian a écrit :
The current situation is the worst of both worlds
-- we don't provide
enough information to accurately identify the link type without
examining the URL, but we also require some arbitrary distinction to
be made in the rel attribute.
Yes, I'm not against more information.
Emmanuel
--
Kiwix - Wikipedia Offline & more
* Web:
http://www.kiwix.org
* Twitter:
https://twitter.com/KiwixOffline
* more:
http://www.kiwix.org/wiki/Communication
_______________________________________________
Wikitext-l mailing list
Wikitext-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
--
(
http://cscott.net)