OASIS XML Localisation Interchange File Format (XLIFF) TC

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. Regards, Fredrik Estreen

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. Regards Jung 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. Regards, 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

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.   Cheers, -yves     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. Regards Jung 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.   Regards, 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

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.. Rgds dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie 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.   Cheers, -yves     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. Regards Jung 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.   Regards, 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

It was an informal support to proceed that way. -ys   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..   Rgds dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto: david.filip@ul.ie 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.   Cheers, -yves     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. Regards Jung 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.   Regards, 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  

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.
 
Regards,
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.
-ys
 

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..


 


Rgds


dF





Dr. David Filip



=======================

LRC CNGL LT-Web CSIS


University of Limerick, Ireland


telephone: +353-6120-2781


cellphone: +353-86-0222-158



facsimile: +353-6120-2734


mailto:
david.filip@ul.ie


 

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.
 
Cheers,
-yves
 
 


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.


Regards
Jung

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.
 
Regards,
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







 

Hi all, I'm just now back in Berlin. Apologies for missing Tuesday's call, but I trust being in transit to another country is a good reason to miss… I read this and am intrigued the the metaHolder element. Would it be possible to see a live example of what it would look like? I don't think I've seen one (or I've missed it), but Jung’s explanation is quite compelling to me. From an implementation standpoint if you want to pass along some sort of internal metadata that may be useful, but you do not have a schema for it (or perhaps it was created ad hoc for a particular one-off project), this seems like a useful way to go, bearing in mind the caveats expressed here. It would seem to hit the sweet spot for situations where something light is needed. But based on what I've read in the trail below, I would end up voting to allow both metaHolder and custom namespaces since I think they meet distinct (albeit related) needs. -Arle Sic scripsit Yves Savourel in May 2, 2012 ad 03:26 : 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.   Cheers, -yves     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.   Regards Jung 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.   Regards, 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

Hi Arle,   There is a proposal on the Feature tracker for this: Preserve metadata without using extensibility. I think the feature has changed a bit from there in the discussions since but the general structure of the XML is there.    See http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29Preservemetadatawithoutusingextensibility   There has also been some more recent discussion, especially in the threads started at : http://lists.oasis-open.org/archives/xliff/201203/msg00021.html http://lists.oasis-open.org/archives/xliff/201203/msg00037.html http://lists.oasis-open.org/archives/xliff/201203/msg00078.html   Regards, Fredrik Estreen   From: Arle Lommel [mailto:alommel@gala-global.org] Sent: den 3 maj 2012 08:44 To: Yves Savourel Cc: 'Jung Nicholas Ryoo'; Estreen, Fredrik; xliff@lists.oasis-open.org Subject: Re: [xliff] Extensibility methods   Hi all,   I'm just now back in Berlin. Apologies for missing Tuesday's call, but I trust being in transit to another country is a good reason to miss…   I read this and am intrigued the the metaHolder element. Would it be possible to see a "live" example of what it would look like? I don't think I've seen one (or I've missed it), but Jung’s explanation is quite compelling to me. From an implementation standpoint if you want to pass along some sort of internal metadata that may be useful, but you do not have a schema for it (or perhaps it was created ad hoc for a particular one-off project), this seems like a useful way to go, bearing in mind the caveats expressed here. It would seem to hit the sweet spot for situations where something light is needed. But based on what I've read in the trail below, I would end up voting to allow both metaHolder and custom namespaces since I think they meet distinct (albeit related) needs.   -Arle   Sic scripsit Yves Savourel in May 2, 2012 ad 03:26 : 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.   Cheers, -yves     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.   Regards Jung 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.   Regards, 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  

Thanks for the pointer to the proper location. I wish I'd been there for the discussion, as this is an interesting issue. I see there is some sense that it is more complex than a namespace, and there are examples to show why this is so, but the apparent discrepancy in complexity is not so straight-forward: in cases where you use an external namespace the complexity is handled elsewhere (in the schema for the namespace), which allows for a very streamlined local representation. In cases where you don't have that schema, metaHolder would seem to provide a way to accomplish things at the price of a more complex local mechanism. If we take both approaches (which I think makes sense) we would need to clearly distinguish the use cases for each one in the documentation (which shouldn't be too hard to do). -Arle Sic scripsit Estreen, Fredrik in May 3, 2012 ad 10:41 : Hi Arle,   There is a proposal on the Feature tracker for this: Preserve metadata without using extensibility. I think the feature has changed a bit from there in the discussions since but the general structure of the XML is there.    See   http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29Preservemetadatawithoutusingextensibility   There has also been some more recent discussion, especially in the threads started at : http://lists.oasis-open.org/archives/xliff/201203/msg00021.html http://lists.oasis-open.org/archives/xliff/201203/msg00037.html http://lists.oasis-open.org/archives/xliff/201203/msg00078.html   Regards, Fredrik Estreen   From:   Arle Lommel [mailto:alommel@gala-global.org]   Sent:   den 3 maj 2012 08:44 To:   Yves Savourel Cc:   'Jung Nicholas Ryoo'; Estreen, Fredrik;   xliff@lists.oasis-open.org Subject:   Re: [xliff] Extensibility methods   Hi all,   I'm just now back in Berlin. Apologies for missing Tuesday's call, but I trust being in transit to another country is a good reason to miss…   I read this and am intrigued the the metaHolder element. Would it be possible to see a live example of what it would look like? I don't think I've seen one (or I've missed it), but Jung’s explanation is quite compelling to me. From an implementation standpoint if you want to pass along some sort of internal metadata that may be useful, but you do not have a schema for it (or perhaps it was created ad hoc for a particular one-off project), this seems like a useful way to go, bearing in mind the caveats expressed here. It would seem to hit the sweet spot for situations where something light is needed. But based on what I've read in the trail below, I would end up voting to allow both metaHolder and custom namespaces since I think they meet distinct (albeit related) needs.   -Arle   Sic scripsit Yves Savourel in May 2, 2012 ad 03:26 : 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.   Cheers, -yves     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.   Regards Jung 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.   Regards, 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  

I think there is still time to join the discussion :)   I my opinion we should avoid having both mechanisms, since that adds complexity without buying us anything. If we allow namespace extensions someone will use them. If we allow the <metaHolder> someone will use it. If we allow both there will be users of both and probably some users that use both at the same time.   For me the key point is to make it easier to ensure interoperability. One of the biggest obstacles to that for me in Xliff 1.2 is the use of third party namespaces. Even if the schema is public it is close to impossible to support them in a generic tool. Besides the difficulty in displaying / interacting with the data in them, they pose a risk to the document validity when editing the document without knowledge of the third party schema and how it works, think references from the extension schema to elements in the core standard. They also invite tools to make complicated extensions of the standard that is hard to support in other tools and thus often break when the file is processed by such tools.   The <metaHolder> / <prop-group> style extensibility provides a more restricted extension method that will likely be easier to support cross tools. Obviously it will not remove the fact that you can make extensions that is not interoperable. But at least it is less inviting to do so. I also think it is easier for us creating the standard to impose narrow processing expectations on these elements that improve the interoperability, than it is to restrict the workings of third party namespace extensions. Finally the point I raised in the beginning of this thread about the ability to display / interact with unknown data is appealing to me.   I do see the benefit of using namespace extensions to create proprietary extensions. Adding a new attribute to an existing node to attach some data is more elegant than adding it in a key/value group. Not to speak of more complicated extensions. It is just that I do not believe we can achieve good interoperability and allow that at the same time.   For the extensions created by us as ‘modules’ we should of course use namespaces. But here we are in control of both the core and all the extensions and it would be a defect in the standard if the extensions do not work well with tools that do not support them. So we need to take carte when defining them   Regards, Fredrik Estreen   From: Arle Lommel [mailto:alommel@gala-global.org] Sent: den 3 maj 2012 11:02 To: Estreen, Fredrik Cc: Yves Savourel; 'Jung Nicholas Ryoo'; xliff@lists.oasis-open.org Subject: Re: [xliff] Extensibility methods   Thanks for the pointer to the proper location. I wish I'd been there for the discussion, as this is an interesting issue. I see there is some sense that it is more complex than a namespace, and there are examples to show why this is so, but the apparent discrepancy in complexity is not so straight-forward: in cases where you use an external namespace the complexity is handled elsewhere (in the schema for the namespace), which allows for a very streamlined local representation. In cases where you don't have that schema, metaHolder would seem to provide a way to accomplish things at the price of a more complex local mechanism. If we take both approaches (which I think makes sense) we would need to clearly distinguish the use cases for each one in the documentation (which shouldn't be too hard to do).   -Arle   Sic scripsit Estreen, Fredrik in May 3, 2012 ad 10:41 : Hi Arle,   There is a proposal on the Feature tracker for this: Preserve metadata without using extensibility. I think the feature has changed a bit from there in the discussions since but the general structure of the XML is there.    See   http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29Preservemetadatawithoutusingextensibility   There has also been some more recent discussion, especially in the threads started at : http://lists.oasis-open.org/archives/xliff/201203/msg00021.html http://lists.oasis-open.org/archives/xliff/201203/msg00037.html http://lists.oasis-open.org/archives/xliff/201203/msg00078.html   Regards, Fredrik Estreen   From:   Arle Lommel [mailto:alommel@gala-global.org]   Sent:   den 3 maj 2012 08:44 To:   Yves Savourel Cc:   'Jung Nicholas Ryoo'; Estreen, Fredrik;   xliff@lists.oasis-open.org Subject:   Re: [xliff] Extensibility methods   Hi all,   I'm just now back in Berlin. Apologies for missing Tuesday's call, but I trust being in transit to another country is a good reason to miss…   I read this and am intrigued the the metaHolder element. Would it be possible to see a "live" example of what it would look like? I don't think I've seen one (or I've missed it), but Jung’s explanation is quite compelling to me. From an implementation standpoint if you want to pass along some sort of internal metadata that may be useful, but you do not have a schema for it (or perhaps it was created ad hoc for a particular one-off project), this seems like a useful way to go, bearing in mind the caveats expressed here. It would seem to hit the sweet spot for situations where something light is needed. But based on what I've read in the trail below, I would end up voting to allow both metaHolder and custom namespaces since I think they meet distinct (albeit related) needs.   -Arle   Sic scripsit Yves Savourel in May 2, 2012 ad 03:26 : 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.   Cheers, -yves     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.   Regards Jung 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.   Regards, 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    

Hi all, I tend to agree with Fredrik's general assessment of metaHolder and custom namespace: one is simpler and can be handled more generically, the other is more powerful but less easy to work with generically. Now a question (seemingly un-related, but bare with me for a while): What are the processing expectations for an optional XLIFF module (e.g. like <matches>) for a tool that does not support that module? Concretely, for example, if Tool A does not support <matches>, is the tool expected to try to preserve it? Is it expected to somehow set some flag on it if the segmentation changes and affect <matches>? In other words: what type of generic processing do we expect a tool to do on the elements of the XLIFF modules it does not support? Cheers, -yves

Yves, how could <metaHolder> be used to define unique characteristics about particular inline XLIFF tags contained in the translatable text?

The examples I've seen have been where the meta information applies to the entire <unit>.

<unit id=”a1”>
 <segment>
   <source> This is orders of magnitude faster than swept analysis techniques.</source>
 </segment>
 <metaHolder type=”x-attributes”>
   <meta key=”rev”>c</meta>
   <meta key=”id”>g_3423_spectrum</meta>
   <meta key=”alt” id="a1.a">It's orders of magnitude faster</meta>
 </metaHolder>
 <metaHolder type=”count”>
   <meta key=”words”>2</meta>
   <meta key=”chars”>13</meta>
 </metaHolder>
</unit>

But what if you wanted to add unique information about each of the variables, like type of data, maximum length, special considerations, etc.?

<unit id=”a1”>
 <segment>
   <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>
 </segment>





David

Corporate Globalization Tool Development
EMail:  waltersd@us.ibm.com          
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

CHKPII:                     http://w3-03.ibm.com/globalization/page/2011
TM file formats:     http://w3-03.ibm.com/globalization/page/2083
TM markups:         http://w3-03.ibm.com/globalization/page/2071


Yves Savourel ---05/02/2012 06:27:28 AM---Hi Fredrik, Jung,

From: Yves Savourel <ysavourel@enlaso.com>
To: "'Jung Nicholas Ryoo'" <jungwoo.ryoo@oracle.com>, "'Estreen, Fredrik'" <Fredrik.Estreen@lionbridge.com>
Cc: <xliff@lists.oasis-open.org>
Date: 05/02/2012 06:27 AM
Subject: RE: [xliff] Extensibility methods
Sent by: <xliff@lists.oasis-open.org>



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.
 
Cheers,
-yves
 
 
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.

Regards
Jung

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.
 
Regards,
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  

  David,   In the same way you can’t define extensions inside <source> or <target> in XLIFF 1.2, we should not allow custom extensions inside <source> or <target> in XLIFF 2.0. This means, from my point of view, that custom extensions should not be allowed for inline elements neither using <metaHolder> nor using namespaces.   Regards, Rodolfo -- Rodolfo M. Raya       rmraya@maxprograms.com Maxprograms       http://www.maxprograms.com   From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Walters Sent: Friday, May 04, 2012 12:09 PM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] Extensibility methods   Yves, how could <metaHolder> be used to define unique characteristics about particular inline XLIFF tags contained in the translatable text? The examples I've seen have been where the meta information applies to the entire <unit>. <unit id=”a1”>  <segment>    <source> This is orders of magnitude faster than swept analysis techniques.</source>  </segment>  <metaHolder type=”x-attributes”>    <meta key=”rev”>c</meta>    <meta key=”id”>g_3423_spectrum</meta>    <meta key=”alt” id="a1.a">It's orders of magnitude faster</meta>  </metaHolder>  <metaHolder type=”count”>    <meta key=”words”>2</meta>    <meta key=”chars”>13</meta>  </metaHolder> </unit> But what if you wanted to add unique information about each of the variables, like type of data, maximum length, special considerations, etc.? <unit id=”a1”>  <segment>    <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>  </segment> David Corporate Globalization Tool Development EMail:   waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 Yves Savourel ---05/02/2012 06:27:28 AM---Hi Fredrik, Jung, From: Yves Savourel < ysavourel@enlaso.com > To: "'Jung Nicholas Ryoo'" < jungwoo.ryoo@oracle.com >, "'Estreen, Fredrik'" < Fredrik.Estreen@lionbridge.com > Cc: < xliff@lists.oasis-open.org > Date: 05/02/2012 06:27 AM Subject: RE: [xliff] Extensibility methods Sent by: < xliff@lists.oasis-open.org > 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.   Cheers, -yves     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. Regards Jung 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.   Regards, 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  

Hi David, > Yves, how could <metaHolder> be used to define unique > characteristics about particular inline XLIFF tags > contained in the translatable text? We do have a requirement for this in the inline markup requirement (4.5. "Must allow to associate spans of content with metadata"). I think it is an important one, and we need a solution for it to allow XLIFF to work in today's environment. A lot of tools do associate extra metadata with spans of content. I see two ways to do it (regardless of their merits): - with custom namespace you could have attributes in a custom namespace. - with both custom namespaces and metaHolder we could somehow link an inline code or marker with an element (e.g. meta, or metaHolder, or a custom element) using an ID of some sort. For example, using metaHolder, maybe something like: <unit id=”a1”> <segment> <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source> <m:metaHolder> <m:meta type="variable" inlineRef="1">user variable info</m:meta> <m:meta type="variable" inlineRef="2">date1 variable info</m:meta> <m:meta type="variable" inlineRef="3">date2 variable info</m:meta> </m:metaHolder> </segment> Depending on what the actual information to attach is, this example may be a bad one: For instance if the info is just some text representation of the variable we should use the proper XLIFF mechanism for this rather than a custom extension, so the disp attribute probably. But regardless of the example, the principle would be the same. Another way, that Rodolfo suggested, would be to have some form of offset information that would allow to link the metadata and the span, without using markers in the content. Something like this: <unit id=”a1”> <segment> <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source> <m:metaHolder> <m:meta type="variable" offset="24:1">user variable info</m:meta> <m:meta type="variable" inlineRef="47:1">date1 variable info</m:meta> <m:meta type="variable" inlineRef="72:1">date2 variable info</m:meta> </m:metaHolder> </segment> Here I assumed each code would be counted as one char, and since the info applies only to the code its length is 1 char. This method has many advantages, but also some majors drawbacks like making any manual edit basically impossible, or making it very hard for XML tools like XSLT to work efficiently (they would work a lot better with markers) I'm sure there are other ways and variations of those to link the content with the metadata. The important part is that we take this requirement into account when deciding between a metaHolder-type of representation or custom namespaces. Cheers, -yves

Thanks for the clarification.

Personally, I would much prefer referencing the ID value than trying to  use the character position.  The inline element is easily located in the <target> text using the ID value without having to access the <source> text, whereas the character position can only be used with the <source> text.  Also, mixing character position and length in the same attribute seems less desirable than having 2 separate attributes.  Where do you draw the line on combining unrelated information into one attribute?


<unit id=”a1”>
<segment>
  <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>
 <m:metaHolder>
  <m:meta type="variable" inlineRef="1">user variable info</m:meta>
  <m:meta type="variable" inlineRef="2">date1 variable info</m:meta>
  <m:meta type="variable" inlineRef="3">date2 variable info</m:meta>
 </m:metaHolder>
</segment>

David

Corporate Globalization Tool Development
EMail:  waltersd@us.ibm.com          
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

CHKPII:                     http://w3-03.ibm.com/globalization/page/2011
TM file formats:     http://w3-03.ibm.com/globalization/page/2083
TM markups:         http://w3-03.ibm.com/globalization/page/2071


Yves Savourel ---05/04/2012 03:07:04 PM---Hi David, > Yves, how could <metaHolder> be used to define unique

From: Yves Savourel <ysavourel@enlaso.com>
To: David Walters/Rochester/IBM@IBMUS
Cc: <xliff@lists.oasis-open.org>
Date: 05/04/2012 03:07 PM
Subject: RE: [xliff] Extensibility methods



Hi David,

> Yves, how could <metaHolder> be used to define unique
> characteristics about particular inline XLIFF tags
> contained in the translatable text?

We do have a requirement for this in the inline markup requirement (4.5. "Must allow to associate spans of content with metadata").

I think it is an important one, and we need a solution for it to allow XLIFF to work in today's environment. A lot of tools do associate extra metadata with spans of content.

I see two ways to do it (regardless of their merits):

- with custom namespace you could have attributes in a custom namespace.
- with both custom namespaces and metaHolder we could somehow link an inline code or marker with an element (e.g. meta, or metaHolder, or a custom element) using an ID of some sort.

For example, using metaHolder, maybe something like:

<unit id=”a1”>
<segment>
  <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>
 <m:metaHolder>
  <m:meta type="variable" inlineRef="1">user variable info</m:meta>
  <m:meta type="variable" inlineRef="2">date1 variable info</m:meta>
  <m:meta type="variable" inlineRef="3">date2 variable info</m:meta>
 </m:metaHolder>
</segment>

Depending on what the actual information to attach is, this example may be a bad one: For instance if the info is just some text representation of the variable we should use the proper XLIFF mechanism for this rather than a custom extension, so the disp attribute probably.

But regardless of the example, the principle would be the same.

Another way, that Rodolfo suggested, would be to have some form of offset information that would allow to link the metadata and the span, without using markers in the content. Something like this:

<unit id=”a1”>
<segment>
  <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>
 <m:metaHolder>
  <m:meta type="variable" offset="24:1">user variable info</m:meta>
  <m:meta type="variable" inlineRef="47:1">date1 variable info</m:meta>
  <m:meta type="variable" inlineRef="72:1">date2 variable info</m:meta>
 </m:metaHolder>
</segment>

Here I assumed each code would be counted as one char, and since the info applies only to the code its length is 1 char.

This method has many advantages, but also some majors drawbacks like making any manual edit basically impossible, or making it very hard for XML tools like XSLT to work efficiently (they would work a lot better with markers)

I'm sure there are other ways and variations of those to link the content with the metadata.

The important part is that we take this requirement into account when deciding between a metaHolder-type of representation or custom namespaces.

Cheers,
-yves

Hi David,   I agree: Using offsets would have probably too many drawbacks.   I was mentioning that notation because it does have some advantages and I wanted to list all the different options.   Cheers, -yves     From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Walters Sent: Monday, May 07, 2012 11:37 AM To: Yves Savourel Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] Extensibility methods   Thanks for the clarification. Personally, I would much prefer referencing the ID value than trying to  use the character position.  The inline element is easily located in the <target> text using the ID value without having to access the <source> text, whereas the character position can only be used with the <source> text.  Also, mixing character position and length in the same attribute seems less desirable than having 2 separate attributes.  Where do you draw the line on combining unrelated information into one attribute? <unit id=”a1”> <segment>   <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>  <m:metaHolder>   <m:meta type="variable" inlineRef="1">user variable info</m:meta>   <m:meta type="variable" inlineRef="2">date1 variable info</m:meta>   <m:meta type="variable" inlineRef="3">date2 variable info</m:meta>  </m:metaHolder> </segment> David Corporate Globalization Tool Development EMail:   waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 Yves Savourel ---05/04/2012 03:07:04 PM---Hi David, > Yves, how could <metaHolder> be used to define unique From: Yves Savourel < ysavourel@enlaso.com > To: David Walters/Rochester/IBM@IBMUS Cc: < xliff@lists.oasis-open.org > Date: 05/04/2012 03:07 PM Subject: RE: [xliff] Extensibility methods Hi David, > Yves, how could <metaHolder> be used to define unique > characteristics about particular inline XLIFF tags > contained in the translatable text? We do have a requirement for this in the inline markup requirement (4.5. "Must allow to associate spans of content with metadata"). I think it is an important one, and we need a solution for it to allow XLIFF to work in today's environment. A lot of tools do associate extra metadata with spans of content. I see two ways to do it (regardless of their merits): - with custom namespace you could have attributes in a custom namespace. - with both custom namespaces and metaHolder we could somehow link an inline code or marker with an element (e.g. meta, or metaHolder, or a custom element) using an ID of some sort. For example, using metaHolder, maybe something like: <unit id=”a1”> <segment>   <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>  <m:metaHolder>   <m:meta type="variable" inlineRef="1">user variable info</m:meta>   <m:meta type="variable" inlineRef="2">date1 variable info</m:meta>   <m:meta type="variable" inlineRef="3">date2 variable info</m:meta>  </m:metaHolder> </segment> Depending on what the actual information to attach is, this example may be a bad one: For instance if the info is just some text representation of the variable we should use the proper XLIFF mechanism for this rather than a custom extension, so the disp attribute probably. But regardless of the example, the principle would be the same. Another way, that Rodolfo suggested, would be to have some form of offset information that would allow to link the metadata and the span, without using markers in the content. Something like this: <unit id=”a1”> <segment>   <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source>  <m:metaHolder>   <m:meta type="variable" offset="24:1">user variable info</m:meta>   <m:meta type="variable" inlineRef="47:1">date1 variable info</m:meta>   <m:meta type="variable" inlineRef="72:1">date2 variable info</m:meta>  </m:metaHolder> </segment> Here I assumed each code would be counted as one char, and since the info applies only to the code its length is 1 char. This method has many advantages, but also some majors drawbacks like making any manual edit basically impossible, or making it very hard for XML tools like XSLT to work efficiently (they would work a lot better with markers) I'm sure there are other ways and variations of those to link the content with the metadata. The important part is that we take this requirement into account when deciding between a metaHolder-type of representation or custom namespaces. Cheers, -yves

Hi David, > Yves, how could <metaHolder> be used to define unique > characteristics about particular inline XLIFF tags > contained in the translatable text? We do have a requirement for this in the inline markup requirement (4.5. "Must allow to associate spans of content with metadata"). I think it is an important one, and we need a solution for it to allow XLIFF to work in today's environment. A lot of tools do associate extra metadata with spans of content. I see two ways to do it (regardless of their merits): - with custom namespace you could have attributes in a custom namespace. - with both custom namespaces and metaHolder we could somehow link an inline code or marker with an element (e.g. meta, or metaHolder, or a custom element) using an ID of some sort. For example, using metaHolder, maybe something like: <unit id=”a1”> <segment> <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source> <m:metaHolder> <m:meta type="variable" inlineRef="1">user variable info</m:meta> <m:meta type="variable" inlineRef="2">date1 variable info</m:meta> <m:meta type="variable" inlineRef="3">date2 variable info</m:meta> </m:metaHolder> </segment> Depending on what the actual information to attach is, this example may be a bad one: For instance if the info is just some text representation of the variable we should use the proper XLIFF mechanism for this rather than a custom extension, so the disp attribute probably. But regardless of the example, the principle would be the same. Another way, that Rodolfo suggested, would be to have some form of offset information that would allow to link the metadata and the span, without using markers in the content. Something like this: <unit id=”a1”> <segment> <source> The password for user <x id="1"/> was last modified on <x id="2"/> and must be changed by <x id="3"/>.</source> <m:metaHolder> <m:meta type="variable" offset="24:1">user variable info</m:meta> <m:meta type="variable" inlineRef="47:1">date1 variable info</m:meta> <m:meta type="variable" inlineRef="72:1">date2 variable info</m:meta> </m:metaHolder> </segment> Here I assumed each code would be counted as one char, and since the info applies only to the code its length is 1 char. This method has many advantages, but also some majors drawbacks like making any manual edit basically impossible, or making it very hard for XML tools like XSLT to work efficiently (they would work a lot better with markers) I'm sure there are other ways and variations of those to link the content with the metadata. The important part is that we take this requirement into account when deciding between a metaHolder-type of representation or custom namespaces. Cheers, -yves