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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

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


Subject: RE: [xliff] RE: Call for dissent csprd01 comments 007, 008, and 027 - have internal/external option in resource data module AND csprd01 comment 028 referencing in modules


Hi Ryan, all,

 

A few thoughts:

 

-- 1) I’m a bit concerned by seeing all those references used all over the place. When we worked on the inline markup one of the things we identified, at the time, that there was an interest in keeping all things related to a <unit> within a <unit>. That’s why <originalData> is not at the file level for example.

 

For my recent exposure to ITS’ standoff markup implementation, I know it can be very difficult to add/update/read such data when working with stream-based parsers (vs. DOM).

 

I do understand there might be some cases when the advantages of this outweigh the drawbacks, but it’s important that we keep those “long reaching” relationships few and well argumented.

 

-- 2) Another thought is about the naming of attributes referencing other elements. It is quite handy to have explicit names like resourceItemRef (or dataRef, etc.). And that may be needed in some cases where there are different references on the same element. But it may be nice in some cases to use just ‘ref’ if there is no ambiguity as to what the reference is. Maybe resourceItemRef is a candidate for such simplification. (no opinion on that, just wondering).

 

--3) And lastly, I think the amount of important changes (and many changes of changes) we are having during this first review cycle is really demonstrating that the specification needs to be backed up and tested by real implementations. What worries me is not so much the conformance but the implementability.

 

By the way, Ryan: I’m not saying all this specifically for this specific set of changes, but in general.

 

Have a happy 4th of July

 

Cheers,

-yves

 

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Wednesday, July 3, 2013 10:45 PM
To: Dr. David Filip; xliff@lists.oasis-open.org
Cc: bryan.s.schnabel@tektronix.com
Subject: [xliff] RE: Call for dissent csprd01 comments 007, 008, and 027 - have internal/external option in resource data module AND csprd01 comment 028 referencing in modules

 

It wasn’t the last update, after all, sorry. As I was looking closer at referencing with my developers, we realized that a <unit> should be able to reference more than one <res:resourceData> module. The use case would be where segment(s) in the unit appear on more than one screenshot, which the translator wants to see for context while translating. Also, <res:resourceData> is the only module that can appear more than once at a given extension point. So to solve our problem and make the module more consistent, I’m once again changing the proposal (and hopefully *this* is the last time).

Here’s the new proposal. If anybody has suggestions or objections to these changes, please let me know by 10 July. Otherwise, I will consider these issues resolved, and update the spec.

1.      Change <res:source> and <res:target> to be analogous to skeleton (as per TC resolution of comments 007 and 008) in the following manner:

a.        The elements are EITHER empty AND contain an href for an external file reference.

i.                      Mime-type attribute is required

b.        OR they contain XML elements from any namespace and forbid use of href.

i.                      Mime-type attribute is optional                     

2.       Re csprd01 027: Allow <res:resourceData> at <file> and <unit>.

3.       Allow only one <res:resourceData> element on an extension point.

4.       Change <res:resourceData> element to be the grouping parent element, and introduce a <res:resourceItem> element to carry the current id, href, and context attributes.

5.       Remove resourceDataID from <xlf:unit> and introduce the following referencing method instead:

a.        <res:resourceItem> at <unit> level is EITHER empty AND contains a resourceItemRef attribute, which refers to a <res:resourceItem> at <file> level.

b.        OR <res:resourceItem> at <unit> level contains id, href, and context attributes, and child <source> and <target> elements.

Here’s an example of items 2-5:

 

<file>

  <!--screen captures-->

  <res:resourceData>

    <res:resourceItem id="1" mime-type=”image/jpeg” context=”yes”>

      <source href="">

      <target href="">

    </res:resourceItem>

    <res:resourceItem id="2" mime-type=”image/jpeg” context=”yes”>

      <source href="">

      <target href="">

    </res:resourceItem>

  </res:resourceData>

  <unit>

    <segment>…</segment>

   <res:resourceData>

     <!--screen capture references-->

     <res:resourceItem resourceItemRef="1" />

      <res:resourceItem resourceItemRef="2" />

     <!--external resources to resize-->

      <res:resourceItem id="1" mime-type=”text/xml” context=”no”>

        <source href="">

        <target href="">

      </res:resourceItem> 

    </res:resourceData>

  </unit>

</file>

 

Thanks,

Ryan

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Tuesday, July 2, 2013 11:45 PM
To: Dr. David Filip; xliff@lists.oasis-open.org
Cc: bryan.s.schnabel@tektronix.com
Subject: [xliff] RE: Call for dissent csprd01 comments 007, 008, and 027 - have internal/external option in resource data module

 

Sorry, I made a mistake in the proposal. I added <group> to the list of extension points in #2. Additionally, I think it makes sense to rename and make clear the scope of the  resourceDataID attribute now. So, one more, hopefully the last, update to the proposal:

1.     Change <res:source> and <res:target> to be analogous to skeleton (as per TC resolution of comments 007 and 008) in the following manner:

a.      The elements are EITHER empty AND contain an href for an external file reference.

                                          i.     Mime-type attribute is required

b.      OR they contain XML elements from any namespace and forbid use of href.

                                          i.     Mime-type attribute is optional                     

2.      Re csprd01 027: Allow <res:resourceData> at <file> and <unit>.

3.      Rename resourceDataID to resFileRef with the following description: “Resource Data File Reference - Holds a reference to an associated <resourceData> element at the <file> level.

Again, if anybody has suggestions or objections to these changes, please let me know by 09 July. Otherwise, I will consider these issues resolved, and update the spec.

Ryan

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Tuesday, July 2, 2013 3:11 PM
To: Dr. David Filip
Cc: xliff@lists.oasis-open.org; bryan.s.schnabel@tektronix.com
Subject: [xliff] RE: Call for dissent csprd01 comments 007, 008, and 027 - have internal/external option in resource data module

 

Thanks, David, here’s the amendment:

1.     Change <res:source> and <res:target> to be analogous to skeleton (as per TC resolution of comments 007 and 008) in the following manner:

a.      The elements are EITHER empty AND contain an href for an external file reference.

c.      Mime-type attribute is required

b.      OR they contain XML elements from any namespace and forbid use of href.

c.      Mime-type attribute is optional

2.      Re csprd01 027: Allow <res:resourceData> at <file>, <group>, and <unit>

 Again, if anybody has suggestions or objections to these changes, please let me know by 09 July. Otherwise, I will consider these issues resolved, and update the spec.

Ryan

 

From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Tuesday, July 2, 2013 2:06 PM
To: Ryan King
Cc: Dr. David Filip; xliff@lists.oasis-open.org; bryan.s.schnabel@tektronix.com
Subject: Re: Call for dissent csprd01 comments 007, 008, and 027 - have internal/external option in resource data module

 

Ryan, this is a minor comment/ammendment.

I'd say that the mime type attribute will be still necessary in case of external file reference.

This should be expresses as a constraint in the spec.

Remember, we re-qualified some of the PRs as constraints during the F2F, so this is one more case.

 

Cheers

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

 

On Tue, Jul 2, 2013 at 8:30 PM, Ryan King <ryanki@microsoft.com> wrote:

After today’s TC conference call and discussions I am proposing we make the following changes to the Resource Data module:

 

1.      Change <res:source> and <res:target> to be analogous to skeleton (as per TC resolution of comments 007 and 008) in the following manner:

a.      The elements are EITHER empty AND contain an href for an external file reference.

b.      OR they contain XML elements from any namespace and forbid use of href.

c.      Mime-type attribute is made optional

2.      Re csprd01 027: Allow <res:resourceData> at <file>, <group>, and <unit>

 

If anybody has suggestions or objections to these changes, please let me know by 09 July. Otherwise, I will consider these issues resolved, and update the spec.

 

Thanks,

Ryan

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Ryan King
Sent: Thursday, June 27, 2013 2:43 PM
To: Dr. David Filip; xliff@lists.oasis-open.org; bryan.s.schnabel@tektronix.com
Subject: [xliff] RE: Re csprd01 comments 007, 008, and 027 - have internal/external option in resource data module

 

David, I agree 100% with this proposal. I didn’t go this direction initially because I thought the TC was generally against it. However, I think this would greatly improve the usefulness of the module and I would hope others can see that as well now that we showed our use case for the module at the symposium.

 

On a related note, should we reconsider allowing this module at the <unit> level as was requested by Jörg in comment 0217:  …However, for employing this module to provide guidance to the translator or the processing tool it might be misplaced under the <file> element, and could certainly also useful on the <unit> and <segment> level to provide preceding and subsequent contextual content information…

 

Ryan

 

From: Dr. David Filip [mailto:David.Filip@ul.ie]
Sent: Thursday, June 27, 2013 11:00 AM
To: xliff@lists.oasis-open.org; Ryan King; bryan.s.schnabel@tektronix.com
Subject: Re csprd01 comments 007, 008, and 027 - have internal/external option in resource data module

 

Ryan,

 

 

As our developers were working on our experimental XLIFF 2.0 implementation, we figured that places where we could store a simple internal file in 1.2 are gone.

 

skeleton is not suitable for our use case, mda would be a hack..

 

Therefore I propose to change reosource data source and target to be analogical to skeleton (as per TC resolution of comments 007 and 008) in the following sense:

 

To be 

EITHER 

empty AND contain a href for an external file

OR 

contain the external file and forbid use of the href

 

 

Thanks for your attention

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

 



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