Tom, Yves, I am not sure about listing the support schema in our catalog.
Is there a way to mark the schema in the catalog as not part of our OASIS product? at least as a comment, you can reuse the wording from the readme.. I am also going to commit a new printout that has similar wording in the schema listings appendix..
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:
On Mon, Jan 13, 2014 at 4:55 PM, Tom Comerford <> wrote:
Yves, thanks for finding these issues. I've just committed the fixes.
I still need to review the attribute types with respect to where they're actually used, and also I want to reconfirm the default values. Also I need to add the xml.xsd to the catalog.
-----Original Message-----
From: [mailto:] On Behalf Of Yves Savourel
Sent: Monday, January 13, 2014 10:38 AM
To:
Subject: RE: [xliff] Version Control Commit by Tom.Comerford
Thanks for the updated files Tom.
I've noted a few things:
- The schema location for xml.xsd is still http://www.w3.org/2001/xml.xsd, while it should be pointing to the local copy now.
- The "auto" value is missing from the dirValue type.
- normalization_type is defined in the core schema, but only modules refer to that type.
I think it should be defined in the module(s). My concern is that as soon as we need to touch something related to the modules that is somehow included or in the core schema, we have to change the version of the core (including its namespace URI) and that has major consequences on the implementations: they have to adjust their parsing.
- The xliff version attribute is set to fixed="2.0". But we discussed (and I thought agreed) to make this not fixed.
This version indicates the version of the specification, not the version of the schema. So if we change anything in modules or core that value has to change, and the schema/namespace version of the core would have to change. And, as stated above, we want to avoid changing the core namespace version as much as possible. Ideally never.
Cheers,
-ys
-----Original Message-----
From: [mailto:] On Behalf Of
Sent: Sunday, January 12, 2014 10:19 PM
To:
Subject: [xliff] Version Control Commit by Tom.Comerford
Author: Tom.Comerford
Date: 2014-01-13 05:19:15 +0000 (Mon, 13 Jan 2014) New Revision: 407 Web View: https://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/schemas/?rev=407&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 updates: removed module imports from core, fixed xs:any and xs:anyAttribute values, miscellaneous updates per the latest spec
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
