OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Version Control Commit by Tom.Comerford

    Posted 12-17-2013 09:38
    Author: Tom.Comerford Date: 2013-12-17 09:38:11 +0000 (Tue, 17 Dec 2013) New Revision: 370 Web View: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/schemas/?rev=370&sc=1 Modified: trunk/schemas/modules/change_tracking.xsd trunk/schemas/modules/glossary.xsd trunk/schemas/modules/matches.xsd trunk/schemas/modules/resource_data.xsd trunk/schemas/modules/size_restriction.xsd trunk/schemas/modules/validation.xsd trunk/schemas/xliff_core_2.0.xsd Log: schema changes to correspond with the most current specification document


  • 2.  RE: [xliff] Schemas update

    Posted 12-17-2013 13:52
    Hi Tom, all, Thanks for updating the schema Tom. I was starting to look at the latest changes in the schemas and had a few questions and notes: - Shouldn't all the processContents be set to lax now (instead of skip)? - Shouldn't the extension defined in the modules be also ##other/lax rather than ##any/skip? - Shouldn't the references to the modules be deleted in <pc> and replaced by an anyAttribute/##other/lax? - Shouldn't the definition for <xliff>'s version be undefined now (vs. with a fixed value)? - I see that we an anyAttribute on <cp/>: Do we have any module on <cp/>? We've removed FS, Is the remaining attributes are the SLR ones? Does it make sense to have SLR there? The same argument as for FS would make sense: this is just escaping a character, you can't expect XLIFF reader to preserve metadata per character once it is read into the original structure. - Do we still need the imports of the modules in the core? - It seems there are several imports in the modules we could get removed as they are not used. - I had a request about having a local include for xml.xsd. The schemas still use the online one: this completely bog down the speed when using the schemas. Is there a reason to not have a local copy? - The ref attribute in Glossary should probably be anyURI no? (or better NMTOKEN if David pays attention to my notes about avoiding fragment identifiers values for ref in Glossary and Matches). Cheers, -yves


  • 3.  Re: [xliff] Schemas update

    Posted 12-17-2013 14:30
    Thanks Yves, I agree with most points. The modules do not have other becuase I have omitted them so far, I did the other reformulations only for core yesterday I will strive to make the any to other changes in modules by the meeting time 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 http://www.cngl.ie/profile/?i=452 mailto: david.filip@ul.ie On Tue, Dec 17, 2013 at 1:52 PM, Yves Savourel < ysavourel@enlaso.com > wrote: Hi Tom, all, Thanks for updating the schema Tom. I was starting to look at the latest changes in the schemas and had a few questions and notes: - Shouldn't all the processContents be set to lax now (instead of skip)? - Shouldn't the extension defined in the modules be also ##other/lax rather than ##any/skip? - Shouldn't the references to the modules be deleted in <pc> and replaced by an anyAttribute/##other/lax? - Shouldn't the definition for <xliff>'s version be undefined now (vs. with a fixed value)? - I see that we an anyAttribute on <cp/>: Do we have any module on <cp/>? We've removed FS, Is the remaining attributes are the SLR ones? Does it make sense to have SLR there? The same argument as for FS would make sense: this is just escaping a character, you can't expect XLIFF reader to preserve metadata per character once it is read into the original structure. - Do we still need the imports of the modules in the core? - It seems there are several imports in the modules we could get removed as they are not used. - I had a request about having a local include for xml.xsd. The schemas still use the online one: this completely bog down the speed when using the schemas. Is there a reason to not have a local copy? - The ref attribute in Glossary should probably be anyURI no? (or better NMTOKEN if David pays attention to my notes about avoiding fragment identifiers values for ref in Glossary and Matches). Cheers, -yves --------------------------------------------------------------------- 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