These are the guidelines we have been using (this one is for HAVE – but applies to all of our profile work)
The following are the attributes of a HAVE Haiti Profile message that are required:
· A HAVE Haiti Profile message must NOT become a new or additional “standard” (e.g. another Hospital Availability standard or another HAVE 1.0 “version”).
· A HAVE Haiti Profile message must NOT be a Proprietary Format.
· A HAVE Haiti Profile message must comply with the HAVE 1.0 standard.
o A HAVE Haiti Profile message must validate against the HAVE 1.0 standard schema.
o A HAVE Haiti Profile message must validate within the HAVE 1.0 standard namespace with no changes to root elements.
o A HAVE Haiti Profile message must use all required elements (i.e. no deletion of required elements are allowed).
o A HAVE Haiti Profile message must not change attributes for required fields.
The following are recommendations for clarity:
· A HAVE Haiti Profile message may further constrain the HAVE 1.0 standard.*
(* may be thought of as a “constraint schema” against the standard)
· A HAVE Haiti Profile message may add to required element definitions.*
(* only to extend or interpret the definition)
· A HAVE Haiti Profile message may limit size of required elements.
· A HAVE Haiti Profile message may exclude optional elements.
· A HAVE Haiti Profile message may use optional elements in a specific way – as defined for the profile.
Thanks,
Lee
The aim of education should be to teach us rather how to think, than what to think - rather to improve our minds, so as to enable us to think for ourselves, than to load the memory with thoughts of other men. ~Bill Beattie
I’m sorry...Standards are to guarantee interoperability. That’s why they are called standards.
HTML, HTTP, XML, TCP, UDP, IP, 802.11, XHTML, Unicode, CSS, SOAP, WSDL, XSLT, XML Schema, Ethernet, DNS, Arp, RIP, ICMP, Telnet, FTP, SMTP to name a few.
What if cisco made their own profile for RIP?
What if Sun made their own profile for TCP/IP in unix?
EDXL-HAVE and RM need to work without a developer pow-wow beforehand. It’s not CIQ’s fault, we just copy-pasted their schema. If we’re all gonna go off and make our own profiles…why have the standard? I think when you combine the context above standards list into what the “internet” is today you see why…The TC’s official answer to documentation issues and referenced schemas shouldn’t be to tell developers to go off and make their own profiles…I think we are just shooting ourselves in the foot.
NIEM is not a standard…it’s a standard process model for developing data interchanges based on standard terminology; similar to what goes on in a TC, or in Engineering shops across the world every day, it’s a great process and model for developing defined data interchanges based on a common dataset and allowing for cross organization reuse.
-Don
Office: 315-838-2669
Cell: 315-383-1197
I hear you but I don't believe that a standard can guarantee interoperability - and especially not through the use of XSD schema alone. May be if there is only one XML instance that everyone has to adher to - but that is not what people expect.
Notice OASIS standards in general - provide the schema framework for the exchange content - implementers expect to have to test conformance (see Drummond Group work on OASIS conformance testing) and declare interoperability - and someone can still send you something that passes the schema but breaks your backend application.
And to Gary's point - yes - optional is not the schema default - but most standards use optional since the context is unknown and rather than have a situation where a required element is being fudged - its made optional. CIQ is a point in case - which part of an address is required? That is impossible to determine for all 207 postal authorities and then in country mail handling. E.g. USA has 5 possible address formats that the USPS will accept.
Mentioning context - that is another weakness in XSD Schema design - no explicit context mechanism - that allows you to control when something is mandatory or optional. You will be shocked to know that OASIS CAM has explicit context mechanisms - so you can dynamically control that.
Don - at this point in the process here - the schema is what it is. My suggest is to augment that with additional profile tools that can provide the types of interoperability measures you are looking for.
BTW - OASIS CIQ now have the v3 format which is a significant improvement on matching addressing needs and removing the ugly from CIQ v2.