[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [xliff-inline] Teleconference - Nov-9-2010 ACTION ITEM "Iinitialdefinition for "what we code in the XLIFF content"
Hi Yves/all, I got the action item ACTION ITEM: Christian to try to get an initial definition for "what we code in the XLIFF content". My current thinking is that what we are trying to do is the following: 1. Create a conceptual model that represents concepts/entities along with their features/properties and relationships 2. Create a representation for the conceptual model As of now, from my understanding the following classes of concepts/entities have been mentioned with respect to "generic inline markup": a. entities which belong to the original (e.g. inline markup like "em") - we could call them "genuine" inline entities b. entities which supplement/augment the original;annotations that are not available in the original - we could call them "supplementary" entities In addition to the aforementioned classes, the following types of concepts/entities have been mentioned so far: a. "illegal/non-XML" characters b. "special" characters (e.g. & or [] for hotkeys/ accelerator keys) Upon second thought, I am not sure that we will be able to come up with a good, universal definition of "special" characters. I am under the impression that each usage scenario may have its own definition of what is special. Thus, I suggest that we do not talk about "special" characters. If we want to represent any of this, we need a "carrier" (e.g. something that represents the "em" we had in the original). This "carrier" could come in two flavours: 1. attached to the material to which it pertains Example: In You need a new <quote its:term="yes">motherboard</quote> the information that "motherboard" is a term is attached to "motherboard". 2. detached from the material to which it pertains Example: In <text xmlns:its="http://www.w3.org/2005/11/its"; > <its:rules version="1.0"> <its:termRule selector="//term" term="yes" termInfoRefPointer="@target"/> </its:rules> <p>We may define <term target="#TDPV">discoursal point of view</term> as <gloss xml:id="TDPV">the relationship, expressed through discourse structure, between the implied author or some other addresser, and the fiction.</gloss> </p> </text> The information that "discoursal point of view" is a term is detached from it (namely contained in "its:termRule). Putting this all together, I think that we are trying to do the following when we discuss the implementation of generic inline markup: Suggest a representation for - genuine inline entities - supplementary entities related to inline entities - surrogate entities to represent "illegal/non-XML" characters The representation may be attached or detached from the material to which it pertains. Cheers, Christian -----Original Message----- From: Yves Savourel [mailto:ysavourel@translate.com] Sent: Dienstag, 9. November 2010 17:00 To: xliff-inline@lists.oasis-open.org Subject: RE: [xliff-inline] Teleconference - Nov-9-2010 - 14:30 UTC XLIFF Inline Markup Subcommittee Teleconference Summary Nov-9-2010 Action item summary: ACTION ITEM: Christian to try to get an initial definition for "what we code in the XLIFF content". ACTION ITEM: Andrew to research invalid XML chars representation in other formats (not necessarily translation-related). ACTION ITEM: All to work on ideas for how to represent native data (inline or not, etc.) === 1) Admin Minutes of previous meeting: http://lists.oasis-open.org/archives/xliff-inline/201010/msg00005.html Presents: Yves, Dimitra, Asgeir, Andrew, Arle, Milan. === 2) Discussion: Requirements Requirement working page: http://wiki.oasis-open.org/xliff/OneContentModel/Requirements We had several action items: Three were simple edit tasks. They have been done: -- ACTION ITEM: Asgeir to enter the new wordings in the wiki for 1.7 -> Done. -- ACTION ITEM: Yves to update 1.9. with clearer wording. "Must be able to associate each code of the source with its corresponding code in the target" -> Done. -- ACTION Item: Asgeir to add the following guiding principle: "Wherever possible, data categories or representation mechanisms from other standards should be considered. For example: ITS, RDF, etc." -> Done The last action item is the wording of a definition: -- ACTION ITEM: All to try to come up with a definition for the concept that encompasses original markup, accelerators, stuff that is not in the original. basically; what we code in the XLIFF content. -> anyone? Nobody had any proposal for this. ACTION ITEM: Christian to try to get an initial definition. === 3) Topics we may need to tackle first: We addressed backward compatibility last meeting. The two other items to address are: a) conformance Yves: It seems conformance should be tackled by the TC has a whole. We can simple expression processing expectations in our draft and if need to be, depending on the TC discussions outcome, we can adapt them to be part of the conformance or not. All: fine with that. b) methodology to write the document Yves: As for the methodology to write the document: The TC has decided to go with Docbook but does not have template yet. We can easily start our draft in the wiki and adapt it to Docbook when a template becomes available. All: fine with that. === 4) Design/Implementation The page here: http://wiki.oasis-open.org/xliff/OneContentModel/Comparison Is a start for the discussion. The group had most of the meeting time spent on discussing the Option A and B in the wiki. Yves presented option A. Main aspect to storing the native data in attribute rather than element content. One possible issue is preserving whitespaces. One possible solution would be CDATA attributes, or escaped values. Andrew and others added that using attribute values may be less practical in many aspects: (size limit, visually less readable, etc.) There is value in having readable codes. Asgeir noted that when source is used the native data is less relevant. Arle noted that having no native data was not a good option in TMX as some native data may be different between source and target. In some Asian languages for example bold is represented with different codes. Keeping things optional is the answer. Andrew suggested to keep separate two concerns: a) storing native data inline or not b) paired codes vs. start/end codes Also: the use of a displayable text (inline) may help in having the native data out of the way too. We also discussed option B (use of ITS): Milan, Dimitra, Arle were favorable to that: use standards when they are available. Yves was concern with tools not able to deal with different namespaces (but that's a tool issue) Andrew, Asgeir noted that if ITS was used in XLIFF document, we may have to ensure it could be processed as ITS-annotated XML. ACTION ITEM: All to work on ideas for how to represent native data (inline or not, etc.) We discussed invalid characters Yves talked about text-based escaping vs. element. Text-based escaping is less intrusive. Arle noted that element was nice because it's more visible. Andrew wondered about how other applications dealt with that. From old research from Yves; they don't. Qt TS offers a <byte> element for this, but that's all. ACTION ITEM: Andrew to research invalid XML chars representation in other formats (not necessarily translation-related). === 5) Any Other Business? None. Yves: Maybe we could slide the meeting time a bit now that our time zones are more compressed. Will follow by email. Next meeting will be Dec-7 -end --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]