[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: csprd01-27 Resource Data Module Design
|
Hi Jörg, Regarding the following comment you made during the recent XLIFF 2.0 public review: The Resource Data module is yet another data container that specifically can refer to external data, and might also present certain contextual information (see Section 3.1). 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. In addition, further examples should be
provided to clarify the purpose and rational of this module. We are making the following change to the spec to address this and other feedback: ·
Allow <res:resourceData> at <file> and <unit>. ·
We will not allow it at <segment> because the TC voted by ballot to remove all modules and extensions from <segment> to help enable re-segmentation. ·
Allow <res:source> and <res:target> either to reference external resources or to contain elements from any namespace. The following examples will be provided in the spec: In this example, the <reourceData>
module at
<file> level references external XML that contains resource data for a user interface control. The control is the container for
the text “Load Registry Config” and needs to be resized to accommodate the increased length of the string due to translation. The <resourceItemRef> element contained in the
<resourceData> module at
<unit> level provides the reference between them. The name attribute of the
<unit> element could serve as the key for an editor to associate
<source> and <target> text with the resource data contained in the referenced XML and display it for modification. <file> <res:resourceData> <res:resourceItem id="r1" mimeType="text/xml" context="no"> <res:source href="" /> <res:target href="" /> </res:resourceItem>
</res:resourceData> <unit id="1" name="130;WIN_DLG_CTRL_"> <segment id="1" state="translated"> <source>Load Registry Config</source> <target>Registrierungskonfiguration laden</target> </segment> <res:resourceData> <res:resourceItemRef ref="r1" /> </res:resourceData>
</unit> </file> In this example, the
<resourceData> module at the
<unit> level contains elements from another namespace (abc), which could be displayed for modification in an editor that
understands how to process the namespace.
<file> <unit id="1"> <segment id="1" state="translated"> <source>Load Registry Config</source> <target>Registrierungskonfiguration laden</target> </segment> <res:resourceData> <res:resourceItem id="r1" context="no"> <res:source> <abc:resourceType>button</abc:resourceType> <abc:resourceHeight>40</abc:resourceHeight> <abc:resourceWidth>75</abc:resourceWidth> </res:source> <res:target> <abc:resourceType>button</abc:resourceType> <abc:resourceHeight>40</abc:resourceHeight> <abc:resourceWidth>150</abc:resourceWidth> </res:targete> </res:resourceItem> </res:resourceData> </unit> </file> In this example, the
<resourceData> module references multiple static images that may be displayed in an editor to use as context while translating
or reviewing. <file> <res:resourceData> <res:resourceItem id="r1" mimeType="image/jpeg" context="yes"> <res:source xml:lang="en-us" href="" /> <res:target xml:lang="lb-lu" href="" /> <res:reference xml:lang="de-de" href="" /> </res:resourceItem>
<res:resourceItem id="r2" mimeType="image/jpeg" context="yes"> <res:source xml:lang="en-us" href="" /> <res:target xml:lang="lb-lu" href="" /> </res:resourceItem>
</res:resourceData> <unit id="1"> <segment id="1" state="translated"> <source>Remove Registry Config</source>
<target>Registrierungskonfiguration entfernen</target> </segment>
<res:resourceData> <res:resourceItemRef ref="r1" /> <res:resourceItemRef ref="r2" /> </res:resourceData>
</unit> </file> Thanks for your interest in XLIFF 2.0! Ryan -----Original Message----- Hi Chet and Bryan, Many thanks to both of you for your very prompt replies, and the very good explanation of the OASIS processes. This helps a lot in learning and understanding the different steps to standardization of different organization. All the best, Jörg On July 02, 2013 at 15:29 (CEST), Chet Ensign wrote: > Hi Jörg, > > I'm Chet Ensign, the director of standards development at OASIS. I see
> your question to Bryan and thought I would jump in with the answer. > > You asked: "How is the OASIS process with resolving comments, e.g. do
> you need my "official" acceptance of the proposed solution(s), which
> would be similar to the W3C process?" > > At OASIS, we ensure that there is transparency and visibility into the
> work of Technical Committees so that stakeholders in the broader
> marketplace can make their own decisions about the quality of the work. > It is up to each Technical Committee to decide whether and how to act
> on comments received. TCs are required to acknowledge comments
> received, to track them along with their decision on how to resolve
> them, and to post these comment resolution logs at specific stages of
> the process so that those providing comments can see what the TC chose
> to do. There is no requirement that a TC obtain acceptance of a proposed solution. > > You can find this explained in more detail in "Handling the comments
> received during a public review" > (https://www.oasis-open.org/resources/tcadmin/handling-the-comments-received-during-a-public-review). > Of course, TCs like XLIFF that care about the acceptance and adoption
> of their work go beyond this to engage with those who take the time to
> provide thoughtful feedback and seek the best possible solution. > > Thanks for providing your input to the XLIFF & let me know if you have
> any questions on this. I'm happy to go into more detail. > > Best regards, > > /chet > > > > On Tue, Jul 2, 2013 at 5:31 AM, Jörg Schütz <joerg@bioloom.de
> <mailto:joerg@bioloom.de>> wrote: > > Hi Bryan, > > Thanks a lot for your feedback. This looks very good indeed, and I'm > looking forward to the revised version of the specification. And, of > course, some of my comments are still open... > > Regarding the Glossary module it will be also my pleasure to further > discuss remaining issues with Ryan. > > One question: How is the OASIS process with resolving comments, e.g. > do you need my "official" acceptance of the proposed solution(s), > which would be similar to the W3C process? > > Thanks, and all the best, > > Jörg > > On July 01, 2013 at 23:30 (CEST), Schnabel, Bryan S wrote: > > Jörg, > > On behalf of the TC, I want to again thank you for the very useful > comments. As you know, we are tracking them here on our wiki > > <https://wiki.oasis-open.org/xliff/XLIFF%202.0%20Public%20Review%20sub > mitted%20comments%20tracker> > > In an effort to not fill your inbox with individual replies, I > hope you > don’t mind that I will reply to them, but comment number, in > this single > email. > > Several were simply accepted at face value, and will be > implemented (as > documented on the wiki). Also, you and Yves have continued your > discussions publically on the comment list. > > I will address the remainder here. > > csprd01 015 - Processing Requirements for XML PIs: This was also > called > to our attention in comment 013. We had an electronic ballot > (https://www.oasis-open.org/__committees/ballot.php?id=2432 > <https://www.oasis-open.org/committees/ballot.php?id=2432> ), > and voted > to say the Processing Instructions SHOULD be preserved. > > csprd01 018 - Structure and Structural Elements: Glossary > module: This > is also covered in comment 024. We are very close to resolving > this. We > discussed this at the Face to Face meeting in London and came to > consensus > (https://lists.oasis-open.org/__archives/xliff/201306/__msg00009.html > <https://lists.oasis-open.org/archives/xliff/201306/msg00009.html>), > We > then held a ballot > (https://www.oasis-open.org/__apps/org/workgroup/xliff/__ballot.php?id=2438 > <https://www.oasis-open.org/apps/org/workgroup/xliff/ballot.php?id=2438>) > and voted to remove Glossary from File. In summary: A] make Glossary > Module more expressive: 1) make <glossentry> extensible by both > elements > and attributes, 2) make children extensible by attributes, 3) > Introduce > id to be able to reference back from <mrk type="term">; B] Remove > <glossary> from <file> > > Ryan King is the owner of this topic and will be happy to follow > up if > you have further questions. > > csprd01 025 - Format Style Module: I am grateful for this good > advice. I > will add a robust, more sophisticated example that supports images. > > csprd01 026 - Metadata Module: This is also tied to comment 048. > I think > it is very good advice. I will add the example you suggest. > > Prior to the second public review I will send you a link to the > improved > specification that incorporated the comments you sent, and I > will ask > for your opinion of the resolution of your comments. > > Thank you, > > Bryan > > > -- > This publicly archived list offers a means to provide input to the > OASIS XML Localisation Interchange File Format (XLIFF) TC. > > In order to verify user consent to the Feedback License terms and > to minimize spam in the list archive, subscription is required > before posting. > > Subscribe:
xliff-comment-subscribe@lists.__oasis-open.org > <mailto:xliff-comment-subscribe@lists.oasis-open.org> > Unsubscribe:
xliff-comment-unsubscribe@__lists.oasis-open.org > <mailto:xliff-comment-unsubscribe@lists.oasis-open.org> > List help:
xliff-comment-help@lists.__oasis-open.org > <mailto:xliff-comment-help@lists.oasis-open.org> > List archive:
http://lists.oasis-open.org/__archives/xliff-comment/ > <http://lists.oasis-open.org/archives/xliff-comment/> > Feedback License: >
http://www.oasis-open.org/who/__ipr/feedback_license.pdf > <http://www.oasis-open.org/who/ipr/feedback_license.pdf> > List Guidelines: >
http://www.oasis-open.org/__maillists/guidelines.php > <http://www.oasis-open.org/maillists/guidelines.php> > Committee: >
http://www.oasis-open.org/__committees/tc_home.php?wg___abbrev=xliff > <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff> > Join OASIS:
http://www.oasis-open.org/__join/ > <http://www.oasis-open.org/join/> > > > > > -- > > /chet > ---------------- > Chet Ensign > Director of Standards Development and TC Administration > OASIS: Advancing open standards for the information society
> > Primary: +1 973-996-2298 > Mobile: +1 201-341-1393 > > Check your work using the Support Request Submission Checklist at
>
http://www.oasis-open.org/committees/download.php/47248/tc-admin-submi > ssion-checklist.html > > > TC Administration information and support is available at
> http://www.oasis-open.org/resources/tcadmin > > Follow OASIS on: > LinkedIn: http://linkd.in/OASISopen > Twitter: http://twitter.com/OASISopen > Facebook: http://facebook.com/oasis.open -- This publicly archived list offers a means to provide input to the OASIS XML Localisation Interchange File Format (XLIFF) TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe:
xliff-comment-subscribe@lists.oasis-open.org Unsubscribe:
xliff-comment-unsubscribe@lists.oasis-open.org List help:
xliff-comment-help@lists.oasis-open.org List archive:
http://lists.oasis-open.org/archives/xliff-comment/ Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff Join OASIS: http://www.oasis-open.org/join/ |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]