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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitext-l