Schema definitions for APLAWS content types

We are interested in putting together schema definitions for standard
APLAWS content types, with a view to validating content items.

At the moment, some XML Schema definitions are provided in the APLAWS+
source distribution, under documentation. However, these definitions
aren't used in the system anywhere, and there appears to be some
confusion as to whether or not most content items would validate against
them.

The choice of XML Schema as a schema definition language is moot. While
this language permits extremely specific constraints on the structure of
XML documents, it is verbose and unwieldy, and few (free) validating
processors exist for it. Sensible alternatives would be either XML DTDs,
which are small, well understood, fast to process, and have widespread
support (but cannot express all the constraints of more evolved schema
languages), or Relax-NG schemata, which can express all the constraints
of XML Schema definitions more understandably and less verbosely, and
which have a great deal of support in the XML community. Ultimately, the
decision should be made based on the real requirements for validation.

I attach the current schemata reformulated as XML DTDs. As such, we can
already see that some components are overspecified (such as the
mandatory "oid" attribute on many elements) while others are drastically
underspecified, like the "attendees" element in the Minutes content
type, which should probably be reformulated as multiple elements. Also,
the practice of specifying most of the vocabulary with the same local
names but in a different namespace for each content type is a little
bizarre: perhaps we should look at sharing namespaces within the same
document? We should also look at removing duplicates: the Minutes
content type, for instance, provides 3 separate elements for
representing a description.

It would be great if these schemata could become the starting point for
discussion that yields a definitive schematic representation of APLAWS
content. Among other things, such consensus is vital for any kind of
integration between the APLAWS system and other external systems. We
therefore welcome any feedback on the DTDs or on the issue as a whole.

-- 
Redhat-ccm-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-ccm-list
Archives: https://www.redhat.com/pipermail/redhat-ccm-list/