MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] DITA Proposed Feature: Extensibility of DITA through new attributes
Paul Prescod wrote:
> XML's two extensibility mechanisms are elements and attributes. As its
> name implies, extensibility is one of XML's key design criteria.
> Extensbiility (through specialization and customization) is also a key
> part of DITA's design. But DITA only allows the definition of new
> elements, not new attributes, through specialization. There are a
> variety of reasons that people might wish to add their own attributes
> (discussed in the Use Case section).
I'm not sure I completely understand the desired solution. What I think
Paul is asking for is:
1. Provide a mechanism by which a given non-DITA-defined attribute can
be declared to be part of the type and therefore should be preserved
during any generalization actions. Likewise, the attribute becomes part
of the types "interface" and must conform to the rules for that
attribute in any specializations of the type, including whether the
attribute is required, optional, or fixed; any lexical rules; and any
non-lexical semantic rules.
To build on Paul's example, if I want to define a new specialization of
topic and I want it to have "dateChanged" date attribute, I also want to
say that this attribute is an attribute of the type and that any
specializations must conform to the rules for that attribute (for
example, if the attribute is required, specializations must also declare
the attribute as either required or with a fixed default value).
Call these attributes "type attributes", as in "attributes of a type",
as distinguished from "instance attributes", meaning any other
attributes that are not formally defined as attributes of the type.
2. Provide a mechanism by which a given type can indicate whether or not
the declaration of new type attributes is allowed for specializations of
that type.
3. Provide a mechanism by which a given type can indicate whether or not
instance attributes may be declared for instances of the type and, if
instance attributes are allowed, whether those attributes must be
qualified and in a namespace other than one of the DITA-defined name
spaces or the namespace of the type itself.
4. Provide a mechanism for specializing type attributes on
specializations. Specialization would include renaming, restricting
lexical rules, or both.
5. Provide a mechanism for specializing attributes as elements in
specializations. For example, if the base type defines an attribute
named "dateModified=" a specialization of the base type can define an
element named "<dateModified>" and map the dateModified= attribute to it.
The implication of this type of specialization is that the element
specialization of the attribute must be CDATA. That is, in XSD schema
terms, it's data type must be a restriction of the attributes datatype,
and attributes may only be typed with simple types in XSD schema.
6. Provide a mechanism for specializing elements to attributes.
This direction is more problematic unless you impose the restriction
that you can only specialize elements whose datatype (in the XSD sense)
are also valid for attributes.
If this is what Paul is asking for, then I agree that these are useful
features.
I will also observe that items 4, 5, and 6 above will, by their nature,
add significant complication to the processing of DITA-based elements,
as they add indirection that must be resolved whenever processing
instances of DITA-based elements. While this indirection is not too hard
to implement in processors, it has to be done, which means that you
cannot create the sort of naive DITA processors that were an original
design goal of DITA. In particular, you will not be able to simply match
on elements and attributes based only on your knowledge of DITA-defined
types. You'll have to process documents in the context of these
declarations, which means either that the declarations have to be
explicit on each relevant element (in the case of schema-less documents)
or the processing has to be DTD- or Schema-aware (in order to retrieve
fixed attribute values).
I am familiar with the complexity involved because the HyTime standard's
architecture mechanism provides exactly these sorts of features and the
syntax is complicated and significantly complicates architecture-aware
processing.
The ideal solution would be for the XML family of standards to include a
lightweight mechanism that is just for declaring attribute defaults that
could be used without stepping up to full schema-aware processing.
Unfortunately, such mechanism does not yet exist.
Therefore, in the absence of such a mechanism, I would be hesitant to
accept features 4, 5, and 6 as requirements for DITA.
However, some declaration of the specialization constraints I think is
necessary. As such a declaration would only affect DITA validators and
not instance processors, it would not affect the goal of enabling naive
DITA processors as no attribute renaming or remapping would be allowed
if only items 1, 2, and 3 are implemented.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8155
ekimber@innodata-isogen.com
www.innodata-isogen.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]