[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Request approval of "Preserve XML attribute or metadata without extensibility" proposal
Hi Bryan, Could you define what “metadata” means in your example? Is that implying that some of the metadata could be XML element content too? I’m also wondering why XML source documents should have a specific way of being stored? Couldn’t HTML5 metadata be also important for example? Cheers, -yves From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Schnabel, Bryan S I move that we promote the proposed feature, "2.21. (B25) Preserve XML attribute or metadata without extensibility" (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#XLIFF2.0.2BAC8-Feature.2BAC8-PreserveXMLattributeormetadatawithoutextensibility.A.28B25.29PreserveXMLattributeormetadatawithoutextensibility ) to section 1, as an approved feature for XLIFF 2.0 (http://wiki.oasis-open.org/xliff/XLIFF2.0/FeatureTracking#ApprovedFeaturesforXLIFF2.0 ). If any voting member of the TC agrees, please second. Here's some background. Today we nearly always need to use extensibility to preserve source XML attributes when converting an XML file to XLIFF. We should create a way to preserve the attributes using supported XLIFF markup - removing the need to extend. Consider this XML element: <para id="g_3423_spectrum" alt="It's orders of magnitude faster" rev="c">This is orders of magnitude faster than swept analysis techniques.</para> If we were to allow an element like <meta-hold> (would really need to come up with a better name though) to contain the name of the attribute, its value, and optionally its type and translate y/n, we would eliminate the need for extensibility for this use case. Example: <trans-unit id="para-73"> <meta-hold name="id" translate="no">g_3423_spectrum</meta-hold> <meta-hold name="alt" translate="yes">It's orders of magnitude faster</meta-hold> <meta-hold name="rev">c</meta-hold> <source>This is orders of magnitude faster than swept analysis techniques.</source> </trans-unit> I include the following, not to propose to specifically update the schema in this manner, but rather to provide more background on the proposed data types and constraints. Modification to schema: <xsd:element name="meta-hold"> <xsd:complexType mixed="true"> <xsd:group maxOccurs="unbounded" minOccurs="0" ref="xlf:ElemGroup_TextContent"/> <xsd:attribute name="name" type="xsd:string" use="required"/> <xsd:attribute name="type" use="optional"/> <xsd:attribute name="translate" use="optional"/> </xsd:complexType> </xsd:element> Allow the usual inline elements, but do not allow nested <meta-hold> elements <xsd:group name="ElemGroup_TextContent"> <xsd:choice> <xsd:element ref="xlf:g"/> <xsd:element ref="xlf:bpt"/> <xsd:element ref="xlf:ept"/> <xsd:element ref="xlf:ph"/> <xsd:element ref="xlf:it"/> <xsd:element ref="xlf:mrk"/> <xsd:element ref="xlf:x"/> <xsd:element ref="xlf:bx"/> <xsd:element ref="xlf:ex"/> </xsd:choice> </xsd:group> Please feel free to join this discussion if you have questions, concerns, objects, or if you support this idea. Thanks, Bryan Schnabel |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]