[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Metadata extensibility with metaHolder
On behalf of Alan (cc.) and myself, I’d like to make a contribution to the ongoing discussion around metadata extensibility. We’ve been following the conversation with interest and have discussed it among our team here. We view metadata organization and interoperability as important pieces of XLIFF 2.0 and would like to share some implementation thoughts.
Assuming that the initial extensibility vote was passed, we advocate for adoption of the metaHolder element construct for defining extensible metadata in XLIFF documents. The main advantages that we see are:
· Readability & predictable structure
· Avoids disturbance of the translation unit, and the possibility of limiting recycling leverage
We plan to propose a list of common, defined elements that should form part of XLIFF 2.0, but will wait for this extensibility discussion to conclude first. We have a number of business scenarios that would benefit from enabling interoperability among metadata. We see advantages in having transparency in the metaHolder container to enable handling by third-party tools (even if it is limited to partial processing/display of recognizable data types). Flexible extensibility is important to avoid restricting future metadata requirements, but we wish to see metadata types coalesce around common standards (e.g. XML schema datatypes) for maximum interoperability. Our proposal reflects this notion of allowing flexibility with strong definitions.
Given the metaHolder, we suggest some specific implementation details:
1. Add a type attribute to metaHolder
2. Define a set of datatypes for the metaHolder type attribute to allow minimum processing expectations for extensible metadata within the metaHolder element. We have not finalized a definitive list, but we would suggest the following:
a. Select a subset of common datatypes from the XML built-in-primitives datatypes list (http://www.w3.org/TR/xmlschema-2/#built-in-primitive-datatypes), such as string, integer, Boolean, (etc.), with basic processing expectations defined
b. File: allow for reference of metadata in a separate file. Third party tools can use the file type to handle the extensible metadata in predictable ways
c. Regex: allow for inclusion of regular expressions as extensible metadata. Third party tools may include validation or other handling of this metadata
3. Allow the type attribute values to be extended by namespace for:
a. Public schemas, e.g. xmlns:xs="http://www.w3.org/TR/xmlschema-2/" AND
b. Private schemas, e.g. xmlns:Microsoft-WinLoc="http://www.microsoft.com/public/winloc"
i. Note: we do not anticipate universal publication of private schemas, but acknowledge that there will be scenarios requiring the use of custom data types, hence support for this extension. There is no expectation of third-party tool handling for these private schema data types
4. Add a provider attribute to metaHolder. This is the name of the provider/system where the metadata is provided/consumed to describe the source/identity of the data
We have put together a couple of simple examples to illustrate how the above suggestions would look when used with metaHolder.
We look forward to feedback on these suggestions.