[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xliff] Current XLIFF schema. Converting XHTML to XLIFF.
Yves and others, It seems to me that there are really two distinct XML vocabularies. 1) XLIFF which is the structure or framework used to transport the content. This part is really the interchange file format. It is extensible with optional "any" attribute and elements allowed throughout the structure as long as the namespace is different. Here the specification acknowledges that it does not cover all possible uses for XLIFF. Even though XLIFF is for interchange between disparate systems, it allows for system-specific extensions that survive the round-trip. 2) The second vocabulary is for the content itself. This specification is closed and minimalistic. It does not include extensibility, presumably because the content editors are implemented only for the small set of placeholder tags. This also implies that new tags cannot be added to the specification without causing problems to the editors. It appears to me that this part of the specification is very similar to the TMX tags for content. This is my mental model of how the translation process works. My background is as a user of translation services, not a provider. As I see it, the XLIFF data will be passed to an XML processor to extract the <source> and pass it to an editor for translation. That editor is not completely XLIFF aware, but knows only the few tags allowed within <source> and <target> elements, for example, <g> and <ph>. Once the translation is done, the content is re-packaged by an XML processor to return the XLIFF data back to the recipient. XLIFF data <----> XML processor extracts content <----> content translation (allows only a few tags) Please let me know if I am misunderstanding it. To convert any XHTML tag to <g> or other appropriate XLIFF tag, the values for the 'ctype' attribute would have to be either open-ended, allowing any value, for example, ctype="textarea" or have a predefined value, like "other", that would be generic. For example, I would need to convert XHTML paragraphs (<P>) and tables (<TABLE><TBODY><TR><TD>) to <xlf:g> elements. This is how I converted hyperlinks (A) and images (IMG) to XLIFF. <xlf:source>Enter the body text of your <xlf:g ctype="link" id="IDA5A4R">XHTML</xlf:g> document here <xlf:g ctype="image" id="IDAGB4R"></xlf:g> </xlf:source> <xlf:target>...</xlf:target> <xlf:prop-group name="IDA5A4R"> <xlf:prop prop-type="tag"> <a href="http://www.w3.org/xhtml" target="_self" title="eXtensible HTML"></a> </xlf:prop> </xlf:prop-group> <xlf:prop-group name="IDAGB4R"> <xlf:prop prop-type="tag"> <img src="fig1.gif" alt="fig one" width="11" height="21" align="right"></img> </xlf:prop> </xlf:prop-group> Now that prop-group and prop are deprecated, I would use a custom namespace element instead, for example: <xlf:source>Enter the body text of your <xlf:g ctype="link" id="IDA5A4R">XHTML</xlf:g> document here <xlf:g ctype="image" id="IDAGB4R"></xlf:g> </xlf:source> <xlf:target>...</xlf:target> <my:tag name="IDA5A4R"> <a href="http://www.w3.org/xhtml" target="_self" title="eXtensible HTML"></a> </my:tag> <my:tag name="IDAGB4R"> <img src="fig1.gif" alt="fig one" width="11" height="21" align="right"></img> </my:tag> The <my:tag> elements store the original tag name and attributes. BTW, the id values were automatically generated in an XSLT using the XPath function generate-id(). Does this conform with the basic principle behind tagging content? On a slightly different topic, I also have a proprietary vocabulary that I use in the original XHTML document to indicate which parts should be extracted to an XLIFF document for translation. The original XHTML document is essentially an XLIFF skeleton (skl) file. I know there has been some discussion of putting XLIFF tags into XHTML documents, but I did not see how to apply them, so I can up with my own. I only needed two tags: <skl:text> and <skl:block>. Each has a required 'id' attribute, which must be unique. This would seem to be a third XLIFF vocabulary that applies to skeleton files that are XML compliant. I've only recently joined and I don't want to delay the specification process. My hope is to be able to use XLIFF with original XHTML content in a process that is automated as much as possible. I am willing to have these discussions deferred to a more convenient time. Perhaps a case-study or "best practices" document would help me. Do any exist yet for XHTML applications? Regards, Doug Domeny Ektron, Inc. +1 603 594-0249 http://www.ektron.com -----Original Message----- From: Yves Savourel [mailto:ysavourel@translate.com] Sent: Tuesday, December 24, 2002 11:20 AM To: XLIFF Subject: RE: [xliff] Current XLIFF schema Hi Doug and all, I'm just getting back to work and trying to catch up with everything, so I may speak without full understanding of the different discussions you all had the past 2 month, but it seems this one is still going on. My understanding of XLIFF content mechanism is that the format is meant to separate text from codes, using a finite number of inline element that allow to 'abstract' the original codes (regardless of their format). It seems that allowing other elements of another namespace within the content would break that basic principle. I understand that one might want to do a lot of things with an XLIFF document at different stage, like edit it. And using different namespaces in the content is very handy for this. But, in my view, those are proprietary modifications of XLIFF (which can certainly exist without conflict). I think the burden of go from the XLIFF format to those extensions (and back) should reside in whatever tool use the extension. The mandate of XLIFF is to be an exchange format, and as it, in my view, it cannot allow to have extension for the content. Just my first impression on this topic. But I certainly think the subject should be looked at carefully and the advantages (if any) of allowing extensions in the content be considered. kind regards and Merry Christmas -yves -----Original Message----- From: Doug Domeny [mailto:ddomeny@ektron.com] Sent: Wed, December 11, 2002 7:27 AM To: XLIFF Subject: [xliff] Current XLIFF schema Is the latest revision of the XLIFF schema available? I would like to compare it with the one I am currently using. I made a couple small changes/fixes before I joined OASIS and the XLIFF TC. Of particular interest is extensibility of the TextContent to allow non-XLIFF tags, for example XHTML tags. I'm working on an application that includes XHTML tags, (like P, H1, TABLE), in the content. This is not to say that every application would need to support XHTML, only that an application could. Some tags, like A (hyperlink) and IMG, are converted to XLIFF G (placeholder) tags so that the translator is not exposed to URLs. EXAMPLE : <xlf:source> <p>Enter the body text of your <xlf:g ctype="link" id="IDA4A4R">XHTML</xlf:g> document here</p> <xlf:g ctype="image" id="IDAFB4R"/> <p>second Enter the <xlf:g ctype="link" id="IDAOB4R">body</xlf:g> text of your XHTML document here</p> </xlf:source> : RECOMMENDATION Add '<xsd:any namespace="##other" processContents="strict" minOccurs="0"/>', as shown below, if it is not already present. <xsd:group name="ElemGroup_TextContent"> <xsd:choice> <xsd:element name="g" type="xlf:ElemType_g"/> <xsd:element name="bpt" type="xlf:ElemType_bpt"/> <xsd:element name="ept" type="xlf:ElemType_ept"/> <xsd:element name="ph" type="xlf:ElemType_ph"/> <xsd:element name="it" type="xlf:ElemType_it"/> <xsd:element name="mrk" type="xlf:ElemType_mrk"/> <xsd:element name="x" type="xlf:ElemType_x"/> <xsd:element name="bx" type="xlf:ElemType_bx"/> <xsd:element name="ex" type="xlf:ElemType_ex"/> <xsd:any namespace="##other" processContents="strict" minOccurs="0"/> </xsd:choice> </xsd:group> Many other tags are extensible, why not TextContent? Regards, Doug D Ektron, Inc. +1 603 594-0249 http://www.ektron.com ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC