Hi Yves,
Thanks for the friendly reminder.
I like the methodology you suggest.
I have added some ideas for additional options (options B and C). In a nutshell, these options suggest the (re)use of existing namespaces/mechanisms. Both options are aligned with the "Guiding Principle" to shy away from reinventing the wheel.
Unfortunately, I so far did not find the time to show how these options would realize the individual requirements.
One area that is kind of misty is the current point in time, is the possible combination of the different options. My gut feeling is that something that combines something new (option A) with something existing (options B and C) might be something very attractive.
Best regards,
Christian
Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Montag, 1. November 2010 15:47
To: xliff-inline@lists.oasis-open.org
Subject: [xliff-inline] Inline Markup - phase 2
Hi everyone,
Just a note to remind you that we have all an action item for next meeting (Nov-9):
"ACTION ITEM: All to try to come up with a definition for the concept that encompasses original markup, accelerators, stuff that is not in the original. basically; what we code in the XLIFF content."
Also, it would be nice to start getting some ideas down for the new markup.
To that end, I've started a page in the wiki:
http://wiki.oasis-open.org/xliff/OneContentModel/Comparison
The idea is to try to get an overall sense of what are the different possibilities and at the same time to start working toward a common solution.
Let's say I have some ideas on what the new markup should be. I'll call this "Option A". the page has a section that has some details about how Option A works, but it has also a section where all requirements are listed, and for each one we have a concrete example of an original input. Each option should list how that example would be coded
For example:
-----
- Must be able to represent standalone codes
Original: "Before
after"
Option A: "Before