OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


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-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, October 30, 2013 1:23 PM
To: xliff@lists.oasis-open.org
Subject: RE: [xliff] Proposal for issue 103 (to enable a processor to implement only core): two versions of core schema

> 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.


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:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]