OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Extensibility methods

Hi David, Yves,


It would be wrong to say I intended it as a formal proposal for a ballot. Obviously I would like to see such a ballot, but I wanted to send it out for a bit of discussion first. To see if the language was reasonable and if there was a strong opinion against it at this point. At the meeting it felt like there was much more to discuss so I also wanted to leave some room to finish the discussion before proceeding with a ballot. Since there has been positive feedback and no negative so far and relatively little discussion I will send out a formal proposal tomorrow.


One thing I’m not sure about is the timing of the ballots and if they should be done as web ballots or during a conference call. If I remember correctly we allow for two weeks runtime on the web ballots. I think we need to have some time (at least a week) between the end of the first and end of the second. This is to allow potential ‘No’ voters in the first ballot to make up their mind on what is the lesser evil in the second ballot. If not I would expect all ‘No’ in the first to go into the ‘Abstain’ category in the last.


I could see the first ballot being done during the next TC call. And if the result is ‘Yes’ open the second ballot on the web directly following the call for example. If we allow a week for a web ballot we could open one soon and have it finish before the next call and follow up with the next after that call.



Fredrik Estreen


From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: den 2 maj 2012 17:52
To: 'Dr. David Filip'
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] Extensibility methods


It was an informal support to proceed that way.



From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Wednesday, May 02, 2012 9:42 AM
To: Yves Savourel
Cc: Jung Nicholas Ryoo; Estreen, Fredrik; xliff@lists.oasis-open.org
Subject: Re: [xliff] Extensibility methods


Yves, is your +1 a formal second for the two ballots as specified by Fredrik?

In case it is not, I second the proposal of the two ballots in the given order.

It only remains to be seen, if Fredrik meant his formulations as ballot proposals (or just a discussion statement). IMHO they are good to go as is..




Dr. David Filip



University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734


On Wed, May 2, 2012 at 12:26 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi Fredrik, Jung,


At last, good technical reasons to use something like <metaHolder>.


I’m still not convinced it would be better than custom namespaces, but at least now I can see positive implementation aspects to it. I need to chew on that.


+1 for Fredrik’s suggestion on the way to moving forward.






From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Jung Nicholas Ryoo
Sent: Wednesday, May 02, 2012 4:50 AM
To: Estreen, Fredrik
Cc: xliff@lists.oasis-open.org
Subject: Re: [xliff] Extensibility methods


Hi all,

As an intensive user of prop-group/prop, I believe <metaHolder> has its reason to exist, just like C++ keeps struct while C++ class is more object-oriented can replace struct. (No serious arguments on validating this comparison please. :) )

I see the usage of <metaHolder> as a wrapper of data (key-value pairs, again like C++ 'struct'), while the custom extensions should be able to cover more.  Even though another party does not understand the information in <metaHolder>, at least the way of extracting data is very unified. It knows how to extract data, it can show the key-value, and it can index them for search. So translators can utilize such information, or even some tools may let translators design some actions for specific key-value pairs. The definition of content inside <metaHolder> can't be easily delivered across different tools, but the information can be anyway delivered without exchanging the schema or any further information.


On 02/05/2012 11:31, Estreen, Fredrik wrote:

Hi All,
I would like to follow up on yesterday's discussion on the <metaHolder> and namespaces to facilitate extensibility. 
The first thing is a point which I don't think has been discussed before, and that is how easy it would be for a tool to make meaningful use of unknown extension data. At first it might sound like a nonworking or bad idea but I think there are cases where it would add value. In many cases metadata could be made useful even if the tools do not know the exact meaning of it, the problem is finding a good way to present it to the user. Here I believe that <metaHolder> as a grouped key/value store is much simpler to work with than arbitrary XML in a namespace. I also think it would make it simpler to extract the metadata for storage/retrieval in a database.
Specific things that I can see a use for is filtering the document on translation units with a specific key/value pair, or providing URL links to other information (or applications). Generically it would be possible to display (and possibly modify) the unknown data as a grouped property grid allowing the user to interpret the meaning of the data. Creating a query builder interface for a database would also be straight forward. To make the filtering / querying as useful as possible I would recommend to also provide a "datatype" for the "value" so that range queries can be used and appropriate input controls created. I think it makes sense to keep the list short and also allow "unknown" as the default type. So unknown, string, number, url and date feels like a good set to me, but I'm sure there are a few more that other would like to see. Another option if we do not want to specify the list we could use some other standard list like the XML primitive types http://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes and use anySimpleType as the default / unknown.
All of this is possible with XML namespace extensions, but in my opinion it is much more difficult to create user friendly access to the data. A simple but not so user friendly way here is of course to just use XPATH for search and filtering and somehow display the XML fragments to the user.
Second thing is that I like the process/votes suggested David Filip and think we should start down this path to resolve the issue. First one where we simply vote if we want extensibility at all: 
 * 'Yes' for extensibility by some means
 * 'No' for no extensibility at all
 * 'Abstain' for need of more discussion
Second one where we vote on how, using 'Elements', 'Namespaces', 'Elements and Namespaces', 'Abstain' to select how to implement the extensibility, if the 'Yes' votes won the first vote:
 * 'Elements' for extensibility by elements and attributes defined in the XLIFF specification. An example of this method is the proposed <metaHolder> feature.
 * 'Namespaces' for extensibility by allowing third party namespaces at defined locations in the XLIFF documents. As we do in XLIFF 1.2 possibly with additional requirements for conformance and processing expectations.
 * 'Elements and Namespaces' to use both of the above methods to facilitate extensibility.
 * 'Abstain' for need of more discussion
If we choose to allow extensibility and the preferred way(s) to do it we can start looking at the implementation details.
Fredrik Estreen
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org


Jung Nicholas Ryoo | Principal Software Engineer
Phone: +35318031918 | | Fax: +35318031918 |
Oracle WPTG Infrastructure

ORACLE Ireland | Block P5, Eastpoint Business Park Dublin 3

Oracle is committed to developing practices and products that help protect the environment


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]