OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution)

    Posted 12-03-2013 13:52
    Hi all, Continuing on trying to have validation without using modules references in the core. I've run another experiment: I've removed all modules references from the core schema, changed the type of validation of the extensions from skip to lax and used the core, xml, fs, and metadata schemas in the XSD validator I used with Lynx. That seems to works: each element of the given namespaces are validated against their schemas. One things that does not get checked is whether or not a module is allowed a given extension point (because that is not in the core schema anymore). That I believe could be validated by program, based on the modules' specification that would tell where the elements of the modules are expected. I know David that you are worried about not validating all through the schema, but there are other things that cannot be validated by the schema in some modules. So how will be verify those? On a side note: FS is now (latest editor's draft) allowed only on elements that allowed extended attributes, except for <ph>, <pc>, <sc>, and <ec> where the FS attributes and a SLR attributes are allowed but no other non-core attributes are. I think we should just allow any extended attributes on those elements as well: We should be consistent. If a case was made to allow FS and SLR there, it means a case could be made to allow other modules attributes in the future. From a core-only processor view point as soon as you allow a single module somewhere it's the same as making that location an extension point. Cheers, -yves


  • 2.  RE: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution)

    Posted 12-03-2013 16:12
    Hi Yves, I'm quite worried what the consequences of allowing extensions on the inline codes will mean for tool compatibility. We would then have to include how extension namespace attributes should be managed on code cloning and transformation between <pc> and <sc>,<ec> and so on. I doubt that those using extensions there will really conform to our rules on how to modify their extensions. Regards, Fredrik Estreen >


  • 3.  Re: [xliff] proposed solutions for CSPRD 138 (Unique Particle Attribution)

    Posted 12-03-2013 20:34
    I just wanted to note that this was resolved by the ballot the TC conducted today.  I will post minutes based on Lucía's report during tomorrow.. Cheers dF 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 3, 2013 at 4:11 PM, Estreen, Fredrik < Fredrik.Estreen@lionbridge.com > wrote: Hi Yves, I'm quite worried what the consequences of allowing extensions on the inline codes will mean for tool compatibility. We would then have to include how extension namespace attributes should be managed on code cloning and transformation between <pc> and <sc>,<ec> and so on. I doubt that those using extensions there will really conform to our rules on how to modify their extensions. Regards, Fredrik Estreen >