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