(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
View Attach Info

Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-3) was last changed on 21-Mar-2008 13:15 by 67.170.203.183  

This page was created on 17-Jan-2007 22:09 by RaphLevien

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 25 changed one line
Ghestalt simply implements both. This is, however, one of the more unpleasant warts. Clearly, both are not needed, and the presence of single character markup greatly increases the collision risk for people using double character markup. Therefore, I would like to see it resolved one way or another. I don't have a strong feeling for which one to ditch, though - a case can be made for either.
Ghestalt simply implements both. This is, however, one of the more unpleasant warts. Clearly, both are not needed, and the presence of single character markup greatly increases the collision risk for people using double character markup. Therefore, I would like to see it resolved one way or another. I don't have a strong feeling for which one to ditch, though. Both have advantages and disadvantages. Single character markup has much more complicated whitespace rules and is much less flexible for things like subword styling. On the plus side, it's less typing, less of a visual interruption, and extremely natural, as it can be seen in ASCII texts going back decades.
At line 53 changed one line
!!Numbered lists
There is also a potential collision between horizontal line syntax and Crossmark second-level headers. This can be resolved in a number of ways, including requiring a blank line before the horizontal line separator, but is definitely a wart.
At line 55 added 2 lines
!!Lists
At line 59 added 2 lines
A more fundamental issue is that Crossmark uses indentation to indicate list nesting depth. It is possible for a hybrid to implement both schemes with relatively low risk of collision (indentation is unmeaningful in the current Creole draft, so is unlikely to occur), but it's definitely a large wart.
At line 85 changed one line
!!Way forward
== Outcomes ==
At line 87 changed one line
I'd like to get a bit of a sense from both communities about whether this unification effort is worthwhile, or whether I'm just pissing into the wind. Also, for the items above that are relatively easily changed (example: dropping backslash escaping in Crossmark in favor of consistently requiring raw macro), it would be nice to get tentative agreement. Then, I think, the next step is to implement the bastard hybrid of the two so people can play with it.
(Meta: this section was "way forward" in a previous revision)
At line 89 changed one line
If there is then a general sense that it's worth pursuing, I'd like to see focussed discussion on how to remove or at least mitigate the warts. I also wouldn't be surprised if tracking down all the [[CornerCase]]s revealed other areas needing attention.
There are a number of possible outcomes of this unification effort. Which ensues depends a lot on what people //want// to see happen. Feel free to place your name after a section as a very rough straw poll - more detailed discussion should of course go in the Talk page.
At line 91 changed one line
If, on the other hand, we decide that the goals are different enough that we really do need two incompatible standards, then I'll need to choose one or the other for the Ghilbert project -- more likely Crossmark than Creole, but hopefully I won't end up having to make that choice.
=== One spec ===
The most ambitious outcome is that one fully unified markup language results, with one specification. Users would never see formatting errors as a result of cutting and pasting between conformant implementations, and common tools could be developed for things like WYSIWYG editing, formatting to print, smart diff display, and so on.
However, for this to happen, people from both communities would have to actually, like, agree on a bunch of stuff. (cf "bikeshedding")
* [[RaphLevien]] - even though it's probably unrealistic, it would still be best for users, so put me down here.
=== Three specs ===
Both Crossmark and Creole specs continue their development as now. In addition, a third spec emerges describing a bastard hybrid (Creolemark? CrossWiki? CrossCreole?). The primary goal of this hybrid is to correctly process marked-up text from both sources most of the time. Obviously, there would be many corner cases for which this would be problematic, but the spec would include "good practices" recommendations to authors on how to avoid these corner cases and maximize the chances for correct display.
For this to happen, the Crossmark and Creole spec teams need to coordinate to avoid fundamental incompatibilities, such as link syntax and linebreaks. But many of the other inconsistencies can be handled as warts. These warts can be eliminated by agreement between the teams, but in the worst case they simply remain. Perhaps the knowledge that stubbornly holding to one's own bike shed color will force a wart in the hybrid will motivate agreement, but then again, perhaps not.
The user experience will of course be more fragmentary than in the one-spec case, but if most wiki hosts end up going with the hybrid, then cut and paste will generally work. Wikis and documents that will not be receiving much content from the outside can of course go with the simpler implementation alternative of Creole or Crossmark. Tools can be developed for the hybrid, and generally have a pretty good chance of working.
=== Interconversion ===
There are already a couple of dozen smart ASCII approaches. As Grace Hopper said, "The wonderful thing about [Standards|http://en.wikipedia.org/wiki/Standardization] is that there are so many to choose from." Creole and Crossmark simply add two more to the mix. People will just have to deal with fiddling with the markup when porting content from one repository to another. Development of advanced tools remains frustrated by the fragmentation of formats, but over time some might emerge which are very agile at the variant formats, and can even help automate the interconversion.
=== One dies ===
One or the other dies, and nobody cares. Much of the early rivalry between Gnome and KDE had this flavor - proponents of one simply assumed the other would die, so there was no need to compromise in the interests of compatibility. Only after time was it clear that both had a long term future on the desktop, so freedesktop.org emerged as a forum to create common standards for things like drag and drop.
But perhaps in this case one really will die, and then of course the user experience is very good, as the markup spec can stay simple (and the bike shed can be painted a very pretty color), and there will be no impedance mismatch for trying to cut and paste.
Version Date Modified Size Author Changes ... Change note
3 21-Mar-2008 13:15 11.296 kB 67.170.203.183 to previous
2 18-Jan-2007 19:55 11.296 kB RaphLevien to previous | to last way forward -> outcomes
1 17-Jan-2007 22:09 7.781 kB RaphLevien to last initial draft
« This page (revision-3) was last changed on 21-Mär-2008 13:15 by 67.170.203.183