Formalizing the role of extensibility as launch pad for future XLIFF Core or Module features

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

I propose we formalize a concept we've spoken of robustly at TC meetings: Extensibility is the prescribed method for candidate Core or Module features on the way to becoming officially supported by XLIFF.

I think we should put this in an official note (but if putting it in the spec is better, so be it).

I think we should create a TC sanctioned and maintained XML catalog to manage namespaces used for this purpose.

Today we have our official XLIFF namespace catalog:

http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/schemas/catalog.xml

Which we describe in the 2.0 spec:

http://docs.oasis-open.org/xliff/xliff-core/v2.0/csprd01/xliff-core-v2.0-csprd01.html#xml_catalog

I think we should create a cousin catalog that hold names and schema URIs, along the lines of:

<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="urn:oasis:names:tc:{add some name here to indicate these are candidate features}">
    <uri name="myurn.candidatefeature.mygreatfeature" uri="http://myplace/schemas/mygreatfeature.xsd"/>
    <uri name="myurn.candidatefeature2 . . .
    <uri name="myurn.candidatefeature3 . . .
</catalog>

Requirements could be put in place to protect us from frivolous entries (must be a valid schema; must remain accessible; must not compete with existing XLIFF feature, . . . ).

We spoke of this a bit at the last P & L meeting. If I'm leaving out points, please add them.

Thanks,

Bryan