Call for dissent csprd01 comments 007, 008, and 027 - have internal/external option in resource data module

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: