xliff-promotion — archive

[Bryan Schnabel]

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