[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 attributesintendedfor 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 anextensionof 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]