[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 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 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 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]
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:
david.filip@ul.ie 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 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]
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:
david.filip@ul.ie |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]