We had a great discussion this morning in the Templates workgroup. One of the agreements that we came pretty close to making was how to address referencing a templateId in an instance when you are dealing with old-style (version-unaware) templates, and new-style (version aware) templates.
In the old way, this was the correct way to reference a template.
<templateId root='1.2.3.5'/>
In the new way, this is the correct way to reference a specific version of the template.
<templateId root='1.2.3.5' extension='versionLabel'/>
When operating under the old world order, and in the new world order, the first reference to a template identifer in an instance still needs to work.
That's because instances created using version aware templates may still need to refer to other templates that aren't yet version aware (under the new model).
So, the first example above is what I'm calling a version unaware templateId, and the second example is a version aware templateId. The former can only point to a version unaware template definition, and the latter can only point to a version aware template definition.
Instances can use either or both forms. And in fact, this is perfectly legal:
<act>
<templateId root='1.2.3.5'/>
<templateId root='1.2.3.5' extension='versionLabel'/>
...
</act>
In the example above, the instance of the act is declaring conformance to both the version unaware release of the template, and to the newer version aware edition.
The Art-Decor project currenly uses <templateId root='1.2.3.5'> to reference "the current version" of the template, enforcing a "dynamic" constraint to the template. I would argue that any content creator knows WHICH version(s) of a template are being used, and so MUST report the version identifier. That is because versions are allowed to introduce backwards incompatible changes (which is part of why we doing this).
In any case, we will be discussing this further next week.
0 comments:
Post a Comment