Open vs closed Templates - Revision history

Admin: /* What makes an open / closed template? */

2013-08-05T08:59:20Z

‎What makes an open / closed template?

Admin: /* What makes an open / closed template? */

2013-08-05T08:57:21Z

‎What makes an open / closed template?

Admin: /* What makes an open / closed template? */

2013-05-17T10:01:58Z

‎What makes an open / closed template?

Admin: /* What makes an open / closed template? */

2013-05-17T10:00:45Z

‎What makes an open / closed template?

Admin: Created page with "=What makes an open / closed template?= An open template defines what's relevant for that template while allowing undefined contents in the instance. From the perspective of t..."

2013-05-17T10:00:30Z

Created page with "=What makes an open / closed template?= An open template defines what's relevant for that template while allowing undefined contents in the instance. From the perspective of t..."

New page

=What makes an open / closed template?=
An open template defines what's relevant for that template while allowing undefined contents in the instance. From the perspective of the template this undefined content is ignored. This may have benefits if it is to be expected that implementations add additional content, or when you want to cater backward compatibility in a next version of the template.

A closed template defines what's relevant for that template and leaves no room for any other contents in the instance. An instance is considered non-conformant if it contains anything beyond the template definition.

Note that during the publication phase, e.g. for development, testing and qualification purposes, it is possible via a parameter to create schematrons as if everything has @isClosed="true" so any undefined content is detected.

← Older revision		Revision as of 08:59, 5 August 2013
Line 6:		Line 6:
	Open templates allow implementers to develop additional structured content not constrained within for example an implementation guide. Implementers are encouraged to bring their use cases forward to the governance group as candidate requirements to be formalized in a subsequent version of the standard to maximize the use of shared semantics.		Open templates allow implementers to develop additional structured content not constrained within for example an implementation guide. Implementers are encouraged to bring their use cases forward to the governance group as candidate requirements to be formalized in a subsequent version of the standard to maximize the use of shared semantics.

−	Note that during the [[DECOR-Publication\|publication phase]], e.g. for development, testing and qualification purposes, it is possible via a parameter to create schematrons as if everything has @isClosed="true" so any undefined content is detected.	+	{{BestPracticeBox\|Note that during the [[DECOR-Publication\|publication phase]], e.g. for development, testing and qualification purposes, it is possible via a parameter to create schematrons as if everything has <code><nowiki>@isClosed="true"</nowiki></code> so any undefined content is detected.}}

← Older revision		Revision as of 08:57, 5 August 2013
Line 3:		Line 3:

	A closed template defines what's relevant for that template and leaves no room for any other contents in the instance. An instance is considered non-conformant if it contains anything beyond the template definition.		A closed template defines what's relevant for that template and leaves no room for any other contents in the instance. An instance is considered non-conformant if it contains anything beyond the template definition.
		+
		+	Open templates allow implementers to develop additional structured content not constrained within for example an implementation guide. Implementers are encouraged to bring their use cases forward to the governance group as candidate requirements to be formalized in a subsequent version of the standard to maximize the use of shared semantics.

	Note that during the [[DECOR-Publication\|publication phase]], e.g. for development, testing and qualification purposes, it is possible via a parameter to create schematrons as if everything has @isClosed="true" so any undefined content is detected.		Note that during the [[DECOR-Publication\|publication phase]], e.g. for development, testing and qualification purposes, it is possible via a parameter to create schematrons as if everything has @isClosed="true" so any undefined content is detected.

← Older revision		Revision as of 10:01, 17 May 2013
Line 4:		Line 4:
	A closed template defines what's relevant for that template and leaves no room for any other contents in the instance. An instance is considered non-conformant if it contains anything beyond the template definition.		A closed template defines what's relevant for that template and leaves no room for any other contents in the instance. An instance is considered non-conformant if it contains anything beyond the template definition.

−	Note that during the publication phase, e.g. for development, testing and qualification purposes, it is possible via a parameter to create schematrons as if everything has @isClosed="true" so any undefined content is detected.	+	Note that during the [[DECOR-Publication\|publication phase]], e.g. for development, testing and qualification purposes, it is possible via a parameter to create schematrons as if everything has @isClosed="true" so any undefined content is detected.

← Older revision		Revision as of 10:00, 17 May 2013
Line 1:		Line 1:
−	=What makes an open / closed template?=	+	===What makes an open / closed template?===
	An open template defines what's relevant for that template while allowing undefined contents in the instance. From the perspective of the template this undefined content is ignored. This may have benefits if it is to be expected that implementations add additional content, or when you want to cater backward compatibility in a next version of the template.		An open template defines what's relevant for that template while allowing undefined contents in the instance. From the perspective of the template this undefined content is ignored. This may have benefits if it is to be expected that implementations add additional content, or when you want to cater backward compatibility in a next version of the template.