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: Issue #20 (was [dita] Really two issues?)

> ... The feature is specifically for adding new global attributes
> for use as filtering/flagging attributes (what are called "metadata 
> attributes" in the architectural spec). This is suggested to be done 
> via an extension of domain specialization. That extension might 
> also be applicable to other attributes, but not without some work. 

I guess I misunderstood the short problem description: "Extensible
metadata attributes". To me that title is somewhat redundant because all
attributes are metadata and most systems that allow metadata make that
metadata extensible. ;) So I thought that we were just allowing the
attribute set to be extensible (as it should be!).

Is it too late to use a term like "filtering attributes" or "conditional
processing attribute" or "profiling attributes" consistently across DITA

> Adding new attributes to a new element would presumably be an
> of structural specialization. I can imagine there would be ways 
> to accomodate this (equivalent needs for preserving the attribute 
> values in some processable form through the trials and tribulations 
> of generalization and respecialization) but it's not in scope for 
> this feature I think. 

Now I understand a bit better. But perhaps you can help me with a bit
more of a DITA architecture big-picture:

1. Do you consider it a design constraint that a respecialization
(specialization->generalization->respecialization) round-trip be totally

2. If yes, does IBM use lossless respecialization in practice?
Supporting it seems like a noble goal but also one that will
tremendously complicate and constrain DITA's design. I'd like to hear
about some real-world situations you've run into that require that extra

3. If yes, do you think that the issue named "Support for foreign
content vocabularies such as MathML and SVG" is solvable in the 1.1 time

4. If yes, do you think it is reasonable that 1.1 would allow the
invention of whole new elements, and new filtering attributes, but not
random attributes? It seems kind of weird to me. Our customers will tell
us that they need new, proprietary attributes and we'll have to tell
them that they will have to use <unknown>-derived or <data>-derived
elements to simulate attributes.

 Paul Prescod

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