OASIS XML Localisation Interchange File Format (XLIFF) TC

Back to discussions
Expand all | Collapse all

Proposal for issue 103 (to enable a processor to implement only core): two versions of core schema

  • 1.  Proposal for issue 103 (to enable a processor to implement only core): two versions of core schema

    Posted 10-30-2013 19:47
    Hi All,   Regarding issue 103   Yves says:   > For <file> we have: > > - Zero or one <skeleton> element followed by > - Zero or one <notes> element followed by > - Zero or one <mda:metadata> elements followed by > - Zero, one or more <res:resourceData> elements followed by > - Zero or one <slr:profiles> elements followed by > - Zero or one <slr:data> elements followed by > - Zero or one <val:validation> elements followed by > - One or more <unit> or <group> elements in any order followed by > - Zero, one or more elements from any namespace.   . . .   > In other word: one cannot implement a processor > that is only aware of the core.     I think this goes beyond the spec and could also be addressed as a schema issue. What if we had two versions of the core schema, one that has the xi:include for the modules, and one that does not (and of course each having a unique namespace)?   XLIFF 2.0 (only) Core:                     urn:oasis:names:tc:xliff:document:2.0 XLIFF 2.0 Core + modules:            urn:oasis:names:tc:xliff:documentplusmodules:2.0   This is harkens back the XLIFF 1.2 with its strict and transitional schemas.   As for the effect on the spec, I think we would need to define two states for each elements (that allows module element or attributes. For example, for Group we might have something like:   Core State Contains: - One or more <unit> or <group> elements in any order followed by - Zero or one <notes> element followed by - Zero, one or more elements from any namespace.   Core Plus Modules State Contains: - One or more <unit> or <group> elements in any order followed by - Zero or one <notes> element followed by - Zero or one <mda:metadata> elements followed by - Zero or one <slr:data> elements followed by - Zero or one <val:validation> elements followed by - Zero, one or more elements from any namespace.   Core State Attributes: - id, OPTIONAL - name, OPTIONAL - canResegment, OPTIONAL - translate, OPTIONAL - srcDir, OPTIONAL - trgDir, OPTIONAL - attributes from any namespace, OPTIONAL   Core Plus Modules State Attributes: - id, OPTIONAL - name, OPTIONAL - canResegment, OPTIONAL - translate, OPTIONAL - srcDir, OPTIONAL - trgDir, OPTIONAL - fs:fs, OPTIONAL - fs:subFs, OPTIONAL - slr:storageRestriction, OPTIONAL - slr:sizeRestriction, OPTIONAL - slr:sizeInfo, OPTIONAL - slr:sizeInfoRef, OPTIONAL - attributes from any namespace, OPTIONAL    


  • 2.  RE: [xliff] Proposal for issue 103 (to enable a processor to implement only core): two versions of core schema

    Posted 10-30-2013 20:23
    > What if we had two versions of the core schema, > one that has the xi:include for the modules, and > one that does not (and of course each having a unique > namespace)? > > XLIFF 2.0 (only) Core: urn:oasis:names:tc:xliff:document:2.0 > XLIFF 2.0 Core + modules: urn:oasis:names:tc:xliff:documentplusmodules:2.0 I'm pretty sure this is not a good idea to have two namespaces. That would likely bring a massive amount of complications and confusions. > This is harkens back the XLIFF 1.2 with its strict and > transitional schemas. 1.2 may have two schemas, but it has only one namespace. The other problem with linking the solution to schemas is that not all tools are going to validate what element is allowed at a given location using schemas. Remember that the schemas don't allow to validate for everything. Cheers, -yves


  • 3.  RE: [xliff] Proposal for issue 103 (to enable a processor to implement only core): two versions of core schema

    Posted 10-30-2013 22:26
    Yves, Thanks for reminding me about the transitional and strict sharing the same namespace. XLIFF 1.2 did it this way: +++++++++++++++++++++ The XLIFF specification details which items are deprecated and what new constructs to use. Transitional - Applications that produce older versions of XLIFF may still use deprecated items. Deprecated elements and attributes are allowed. Non-XLIFF items are validated only to ensure they are well-formed. Use this variant to validate XLIFF documents that you read. xsi:schemaLocation='urn:oasis:names:tc:xliff:document:1.2 xliff-core-1.2-transitional.xsd' Strict - All deprecated elements and attributes are not allowed. Obsolete items from previous versions of XLIFF are deprecated and should not be used when writing new XLIFF documents. In order for XLIFF documents with extensions to validate, the parser MUST find the schema for namespaced elements and attributes, and elements and attributes MUST be valid. Use this variant to validate XLIFF documents that you create. xsi:schemaLocation='urn:oasis:names:tc:xliff:document:1.2 xliff-core-1.2-strict.xsd' +++++++++++++++++++++ So to be clearer about the option of two different schemas, I still think it would not be complicated or confusing to do it the way we did it before. I did not think this would be the whole solution (I also had some suggestions about updating the spec with two states for core element). I think it would help with one aspect of your challenge, enabling [XML-based] implementers to just support core with their [XML] tools (square braces to show where I inserted my own spin on your words). And of course we all know not all processing requirements can be validated with an XSD.
    Original Message


Related Content