[New-ITS] XML design principles

Tue Jul 18 16:48:27 BST 2006

Ann

So comments in blue on your principles -- I have been working through
the schema guidelines and XML design rules documents that you provided -
and have started putting some rough notes on the wiki.

all the best

Charlie  

Charlie McCay, charlie at RamseySystems.co.uk Ramsey Systems Ltd, 23D
Dogpole, Shrewsbury, Shropshire SY1 1ES

tel 01743 232278 / 07808 570172  skype: charliemccay

________________________________

	From: new-its-bounces at lists.hl7.org.uk
[mailto:new-its-bounces at lists.hl7.org.uk] On Behalf Of
ann.wrightson at bt.com
	Sent: 18 July 2006 14:58
	To: new-its at lists.hl7.org.uk
	Subject: [New-ITS] XML design principles

	Some food for thought:

	1. The "Guiding principles" section of the UN/CEFACT XML Naming
and Design Rules specification includes the following:

	258 * Interchange and Application Use - UN/CEFACT XSD Schema and
instance documents are

	259 intended for business-to-business and
application-to-application use.

	260 * Tool Use and Support - The design of UN/CEFACT XSD Schema
will not make any assumptions

	261 about sophisticated tools for creation, management, storage,
or presentation being available.

	262 * Legibility - UN/CEFACT XML instance documents should be
intuitive and reasonably clear in the

	263 context for which they are designed.

	264 * Schema Features - The design of UN/CEFACT XSD Schema
should use the most commonly

	265 supported features of W3C XSD Schema.

	 2. For reference, here are the desgn principles for the first
XML ITS, as listed on the HL7 wiki:

	*	The transform from the abstract model to the instance
should be as simple as possible. 
	*	The instances should be pleasing to the eye of a human
reader. 
	*	Names should be determined in the abstract model, not
generated by the ITS 
	*	Without compromising the simplicity of the
model-instance transform the instances should be as small as possible.
Thus XML attributes were used for datatype components. 
	*	The ITS should define the set of valid instances for a
V3 artefact, NOT the schema that must be used. This is to allow for
stability of the instances as schema techology improves, and also allows
for the use of different schema for different uses. (see below) 
	*	The ITS should allow for the use of W3C schema for
validation and message description. 
	*	Use attributes to support the population of PSVI
<http://en.wikipedia.org/wiki/PSVI>
(http://en.wikipedia.org/wiki/PSVI). 
	*	CMET references and Wrapper boundaries should be
transparent in the instance. Thus it should be possible to re-package
the way that an interaction is defined by mergeing two wrappers, without
that affecting the instances. (see below) 
	*	Choices should be transparent in the instance - thus a
class should appear in the instance in the same form whether or not it
is part of a choice. This is to allow for forwards compatability when
choices are introduced into models and to reduce the level of nesting 

	3. Here are the suggested principles I presented at the last
face-to-face meeting; the key technical principle that puts usability of
the XML as XML in what is IMO its proper place is highlighted: 

	Usability and Integrity Principles for XML in a new ITS

	Usability principles:

	*	 <cm>useful as an overall test criteria</cm>Instances
are easy to read for a developer with non-specialist UML & XML skills,
using the model-stack as a reference (as far as the DAM) 
	*	 <cm>criteria for implementable model</cm> Element names
are simple and reflect appropriate domain concepts in a way that is
helpful to a human reader, with precision provided by coding. 
	*	 <cm>Naming rules should be set for the implementable
model, but a "Naming and Design Rules" document would be useful for
validating the output XML specifications.</cm> Element names should
conform to generally accepted XML-domain principles for naming, for
example, element names should not show the parentage of the element. The
development of "Naming and Design Rules" documentation for the XML layer
is recommended, as an artefact type well known in the broader XML
community. 
	*	Instance structure is designed for ease of XML
processing (including schema-validation, transformation, storage and
retrieval)  <cm>which means short xPaths, tight schemas, small size,
what else?</cm>  
	*	A specific interoperability interface can be developed
within the XML layer, with design-time reference to the underlying
message models  <cm>not clear what this means</cm> 
	*	When message components are reused across message types,
there should be corresponding XML instance components, where
"corresponding" means "can be processed in the same way by common XML
tools" (suitable invariants needed) 
	*	Priority should be given to supplying schemas that are
designed for efficiency of common XML-technology functions such as
instance validation, code generation, and data mapping for local
integration[1] <outbind://3/#_ftn1> .   <cm>This requirement has an
impact on the definition of the instances (which is fine)</cm> 
	*	Provided XML schemas should give priority to structural
and allowed data content validation over validation of business
semantics; if provided, the latter may be added in a modular, phased
manner for use where required.  <cm>the distinction between data content
and business semantics would need to be established in the abstract
design for this to be robustly followed</cm> 

	Integrity principles:

	*	The content of an XML instance is fully traceable back
(to the relevant DAM and thence ) to the RIM.  It should be possible to
generate the XML from the UML using simple straightforward rules.
<cm>one does not go from the xml to the dam to the RIM -- I suggest that
the content must be traceable to both the DAM and the RIM. </cm> 
	*	An instance of a message model is able to be populated
fully using an XML instance plus a static model of the message type. 
	*	Names of elements and attributes should be determined
from the underlying model(s), not generated by the ITS. 

	XML technical principles:

	*	The ITS  should define the set of valid instances for a
V3 artefact, not the schema that must be used. This is to allow for
stability of the instances as schema technology improves, and also
allows for the use of different schemas for different uses.   <cm>It
mayt be reasonable to follow the lead of CDA, and provide a set of
schemas to which conformance is required (though the schemas tehmselves
do not have to be used).  This addresses the appetite for standard
schemas, without compromising the freedom to use other schemas or none
in a particular implementation.   </cm>  
	*	The transform from an instance of the proximal
underlying model to the XML instance should be as simple as possible,
without compromising the readability and ease of processing of the XML.
<cm> This does not indicate what can be done at the ITS level to protect
readability and ease of processing.   </cm>  
	*	The ITS allows for the use of W3C schema for validation
and message description, and may support the population of PSVI. 
	*	The ITS allows for the use of other schema technologies
such as the ISO DSDL family.

	Ann Wrightson, Martin Bryan & Jay Cousins, July 2006

________________________________

	[1] <outbind://3/#_ftnref1>  The existing ITS could be retained
and developed further as a separate design-time utility for semantic
tracking, model design checking etc)   <cm>I do not see many folk
wanting a separate ITS just for these uses </cm>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.hl7.org.uk/pipermail/new-its/attachments/20060718/d56af11a/attachment.htm