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: Formalizing the role of extensibility as launch pad for future XLIFF Core or Module features

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:


Which we describe in the 2.0 spec:


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

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.



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