[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Best Practice - beyond schema
There are two reasons for needing to go beyond XML Schema on a project that is using XML Schema as its base constraint syntax. The first is where XML Schema cannot express the constraints required, for example, a section of a message that is required if the value of a previous element is "yes", but not if it is "no". Languages such as Schematron go some way to address this and can be used either embedded in an XML Schema schema or as free-standing documents. I will shortly be making recommendations in this area to the UK Govt, and would welcome a discussion here at some point. The other situation, and the one that is a more immediate concern, is the situation where we need to localise a general purpose schema. A good example, since this is an OASIS-hosted group, is the Election Markup Language (EML) on which I have been working. This is an international collaboration, so most elements are optional, although they might be required in a particular situation. For example, some audit information is required in a UK parliamentary election but forbidden in a US gubernatorial or presidential election. It is optional in the schema, but mandatory for the UK and forbidden in the USA. This requirement for profiling schemas is common, but not one I have seen addressed in open discussion. Here are two ways of approaching it: Write new, more restrictive, schemas for each regime such that a document that validates to the local schemas will validate to the global schema (but not necessarily vice versa). This has the advantage that only a single schema processor is required, and it will be an XML Schema processor - something that Governments are generally happy with, while they will be less happy with Schematron or RELAX NG processors. It is also easier to read and understand, since a single schema describes each message. The disadvantage is that we alter the schema document itself, giving us a configuration management headache. Even using derivation, there will be a lot of work developing and checking any new version of the local variant when a new global version is released. or Use an open (open in terms of allowing any content that is not expressly forbidden) schema language to supplement the closed XML Schema schema. Each document will then be validated to the XML Schema schema, then passed on to the second schema processor for the local variations. The advantage is that we do not modify the globally agreed schema. This eases configuration management and conformance checking and means that international systems providers only work with a specific set of schema documents for the additional local constraints, making their job easier. The disadvantage is that we need to operate two schema processors in series, which adds an additional technology and an additional processing overhead. Some of the applications I work on are very high volume, so this can be an issue. I suspect that the former is the short-term pragmatic solution, whilst the latter is the better strategic answer if the technology (in terms of common tools to develop and view two schema languages simultaneously etc) is put in place. How about a tool that provides the graphical editing environment of XML Spy whilst allowing the developer to switch schema language for specific sets of constraints. i.e. I could import an EML schema written in XML Schema, then work on the graphical representation, generating a separate Schematron file whilst leaving the original schema document intact. I throw the discussion open to the floor. Paul Spencer XML Adviser to the Office of the e-Envoy
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|