See also:

http://www.mediawiki.org/wiki/One-pass_parser
http://www.mediawiki.org/wiki/Alternative_parsers

On Mon, May 11, 2009 at 1:22 PM, Brian <[email protected]> wrote:

> I thought it was generally agreed upon that the path to fix the parser goes
> something like this:
>
> * Define a new wiki language that is compatible with bison/flex
> * Write  a converter  between the old language and the new (when possible)
> * Implement per-revision parsers
> * Implement the new parser
> * Begin the migration
>
>
> On Mon, May 11, 2009 at 1:13 PM, Trevor Parscal <[email protected]>wrote:
>
>> On 5/11/09 11:54 AM, Marco Schuster wrote:
>> > On Mon, May 11, 2009 at 8:50 PM, Daniel Schwen<[email protected]>  wrote:
>> >
>> >
>> >> The simple (albeit ugly) solution would to add a parser version field
>> to
>> >> the
>> >> revision table, drag the old parser along as 'legacy', make the new
>>  parser
>> >> the default (and only) option for all new edits, and spit out a warning
>> >> when
>> >> you are editing a legacy revision for the first time. The warning you
>> be
>> >> made
>> >> dependent on the cases that break with the new parser.
>> >> Cases that break could be detected by comparing tidied HTML output from
>> >> both
>> >> parser versions.
>> >>
>> >
>> >
>> > Sounds cool, but it'd require a formalization of MW markup first
>> (something
>> > that should have been done long ago).
>> > What about correcting stuff from "old" behavior to new parser via
>> > bots/update scripts, even for old revisions?
>> >
>> > Marco
>> >
>> >
>> >
>> During the Berlin conference, a very popular and passionate topic of
>> conversation was the need for better testing of MediaWiki. However, if
>> we can't define what it's supposed to do, how can we test it. Last I
>> heard the parser has yet to pass all of the unit-tests written for it,
>> which aren't even very robust. so the concept of the parser's behavior
>> being it's own documentation is clearly conflicting with good software
>> development practices. This said, any changes to the parser cause a risk
>> of breaking old, or even current revisions of articles, which is I've
>> noticed to generally be seen as unacceptable. So - this topic is
>> probably a justifiably touchy one for those involved in working on this
>> software since there's no really elegant solution and lots of complaints.
>>
>> Seems like there's been some general talk about this idea...
>>
>> * Link a revision to a version of the parser
>> * Allow multiple parser versions to co-exist
>> * Provide an upgrade path for revisions to be brought into compatibility
>> with a more modern parser
>>
>> Nothing about this sounds easy, but if we ever want to improve MW markup
>> or parser behavior we will need to do something. Is there any support /
>> criticism for this direction? I'm very curious what other potential
>> directions could be taken which could also result in:
>>
>> * The parser's behavior being a reflection of a well-documented standard
>> * Ability to make changes to MW markup standards over time without
>> abandoning old revisions
>>
>> - Trevor
>> _______________________________________________
>> Wikitech-l mailing list
>> [email protected]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to