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:  [mailto:]
On Behalf Of Ryan King

Sent: Tuesday, July 2, 2013 11:45 PM

To: Dr. David Filip; 

Cc: 

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:
 [mailto:]
On Behalf Of Ryan King

Sent: Tuesday, July 2, 2013 3:11 PM

To: Dr. David Filip

Cc: ;


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:]

Sent: Tuesday, July 2, 2013 2:06 PM

To: Ryan King

Cc: Dr. David Filip; ;


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

mailto: 


 

On Tue, Jul 2, 2013 at 8:30 PM, Ryan King <> 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:
 [mailto:]
On Behalf Of Ryan King

Sent: Thursday, June 27, 2013 2:43 PM

To: Dr. David Filip; 
; 


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:]

Sent: Thursday, June 27, 2013 11:00 AM

To: ; Ryan King;


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

mailto: