OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Element Type Names Don't Matter--Class Is Everything

Eliot Kimber wrote:

> And as I think of it now, this also suggests that the normative 
> definition of the DITA document types should be a "data dictionary" of 
> element classes, not a collection of element types or a DTD. That is, 
> any DTD or schema that reflects the DITA *classes* is only one of an 
> infinite number of possible such DTDs or schemas and therefore any DTD 
> or schema published as a standard would not be *the* definition of the 
> DITA types of merely a conforming implementation of the DITA types. We 
> should certainly publish at least one DTD and one Schema as reference 
> implementation but I don't think they can be *the* normative definition 
> of what the DITA types are.

To repeat what I said to Don in a private conversation:

If we chose we could publish a normative, abstract, "meta" DTD or schema 
that defines the rules for classes *as though* they were concrete 
element types. But this schema would not be directly used by document 

You would still need concrete schemas that implement the mapping and 
reflect the constraints defined in the meta-schema.

Document instances could then be validated against the meta-schema by 
(conceptually) generating an "architectural instance" that reflects the 
class mappings and then validating that instance against the DITA meta-DTD.

For validating schemas and DTDs against the meta-DTD I'm not so sure 
although I'm sure it's possible.

It would probably also be possible to automatically generate both a 
concrete DITA base DTD and concrete schema that reflected the 
meta-DTD--since at the DITA base level the element type names are the 
same as the leaf classes, it's a trivial transform. But those generated 
concrete schemas would be for the convenience of users and implementors, 
not normative definitions of what the DITA types were.


W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]