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] DITA Proposed Feature: Extensibility of DITA through new attributes


Of your six potential requirement I only intended to deal with "1.".

With respect to 2: I see no reason to ALLOW a type to DISALLOW further
extension by its sub-types. It feels like extra work to no benefit.

Similarly, for 3: I don't think that DITA really has a notion of
instance attributes and I don't see a strong argument for it.

With respect to 4, 5 we agree that these are probably beyond scope.

If I'm forced to deal with "6." in order to be compatible with round
tripping through generalization and re-specialization then I could be
talked into it. But I'd like to leave that out of scope as well.

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@innodata-isogen.com] 
Sent: Tuesday, August 30, 2005 7:55 AM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
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]