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


Now that I understand the issue a bit more after this morning's meeting, I agree with Paul - "So I thought that we were just allowing the attribute set to be extensible (as it should be!)."

I know for a fact that if and when my people convert to DITA authoring, we'll need some way to hang arbitrary attributes specific to our application off established DITA elements. We don't care about loss on round-tripping, since these attributes are very application specific. And we'd prefer to avoid a full-blown customization just to make the modest overrides in processing we need based on these attributes.

I don't think it's really fair to define this issue so narrowly now - when a number of us understood it in the broader sense I've just outlined.

What would be so bad about putting in an empty placeholder parameter entity to allow adding arbitrary attributes to any element, with the proviso that they will be ignored by standard processing and consigned to oblivion upon generalization?

Paul Prescod wrote:
... The feature is specifically for adding new global attributes
    
intended 
  
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
specifications?

  
Adding new attributes to a new element would presumably be an
    
extension 
  
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
lossless? 

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
effort.

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
frame?

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]