RE: [xliff-inline] Inline Markup - phase 2

["Lieske, Christian" <christian.lieske@sap.com>]

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 <br/> after"

Option A: "Before <ic id="1" data="&lt;br/>"/> after"
-----
 
This way we can a) be sure each option does have a solution for each requirement, and b) compare the options, and step-by-step work what would be the final proposal we would be all ok with.

I encourage everyone to edit that page and add options. If you have several ideas, use several options. If you have idea only for some of the requirements, fill in only those, etc.

If you see typos or invalid XML anywhere feel free to fix it, but otherwise you probably want to leave someone else's option untouched so it reflects their current view. Modify your own options as we progress: this is an iterative work. 

If possible use the option's own section to present an overall description of that markup. Also, maybe try to identify its shortcomings: someone else may have an idea how to solve those.

I would also recommend to not get attached to element or attribute names to much: they are important, but their functionality is more important. We can debate the most appropriate names once we have agreed on what each does.

Another thing: If you think about a use case of inline code that represent a potential difficult case (and is not covered yet) add an item as if it were a requirement: then people can show the corresponding representation for their option(s).


Suggestions to make the whole process works better is obviously welcome too. This is a starting point.

Cheers,
-yves




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php