RELAX and architectural forms
Date: Thu, 04 May 2000 14:25:03 +0900 From: Murata Makoto <email@example.com> [and Steve Newcomb] To: firstname.lastname@example.org Subject: [reldeve] RELAX and architectural forms
Attached text is written by Steven R. Newcomb of TechnoTeacher. He is well known as a promoter of architectural forms and groves, etc. I got his permission to forward it to this list.
I'm watching the development of RELAX and I'm hoping that RELAX-based systems will meet the following requirements that are today met by DTDs in conjunction with architectural forms (ISO 10744:1997 Annex A.3):
The ability, in schemas, to "inherit" (re-use) the syntactic constraints of other schemas, with the ability to add constraints, to specialize, and to add unrelated additional features, so long as the constraints of the inherited schemas are not violated. In architectural forms (meta-DTDs and the DTDs that refer to them), we can't tell whether the inheriting DTD violates the constraints of the inherited DTD. We can only tell whether an instance violates the DTD and/or any inherited DTD. This is a problem for users of architectural forms because so much expertise is required to write inheriting DTDs.
The ability to check an instance for conformance to the syntactic constraints of all inherited schemas, (both recursively inherited and multiply inherited). Without this, it's probably impossible to have a situation in which there is a one-to-one correspondence between re-usable information sets, re-usable schemas, and re-usable software modules that understand a given information set when it is expressed according to a given schema. There are very important classes of problems (the US healthcare industry's need for electronic information interchange being an example of one of them) for which there is no other workable solution.
The ability to transform an instance into an instance that conforms to any of the schemas that it inherits, without having to write a transformation specification for that purpose, and without having to anticipate all the variations that may be made in inherited schemas by inheriting schemas.
The ability to cause a single element to be recognized as an element type in more than one inherited schema (multiple inheritance), without attribute name collisions, etc.
As my Healthcare Information Management Systems Society slide show (which I'm mailing to you separately) discusses, the requirements that are met by the above capabilities are critical for maintaining reliable business communications in a constantly changing world. I believe that it's vital to distribute control over schemas among the users of those schemas, so that everyone can do what they need to do, but it's also vital to maintain rigorous adherence to common constraints (where the meaning of "common" is highly variable and business-context-dependent).
Prepared by Robin Cover for The XML Cover Pages archive. For AFs, see "Architectural Forms and SGML/XML Architectures." On RELAX: See the reference section "REgular LAnguage description for XML (RELAX)" and the RELAX Web site.