[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for generalized attribute addition
I propose the following: a) We make a new attribute called "otherattrs" (like otherprops but not just for selection/filtering) b) We make a new issue for specializing the "otherattrs" attribute c) We to synchronize the generalization/specialization mechanism for "otherattrs" and "props" In thinking about this, it seems not too difficult at a first approximation. The main two issues are: 1. Escaping paren characters that would otherwise be confused for end-of-attribute-value markers. * This can be solved by having an escaping mechanism like "two paren characters resolve to one, three resolve to two etc. A paren character alone represents an end-of-attribute marker" 2. Keeping track of which attribute values have ALREADY been generalized so that we don't end up escaping the value over and over again (or unescaping it wrongly). * This can be solved with an architectural attribute that lists the attributes that are already generalized. So, for example, I could specialize "otherattrs" with an attribute value that represents the last-changed-date for an element. <myel last-changed-date="2005-08-02T12:28:57(-07:00)"/> Generalized, that might look like: <p otherattrs="last-changed-date(2005-08-02T12:28:57((-07:00)))" generalizedprops="otherattrs"/> Still to think through: a) does this handles multiple levels of specialization well? b) is there a requirement to handle multiple levels of specialization? c) what does the processing (e.g. XSLT or CSS) look like to handle this? d) is there a more elegant solution than "generalizedprops"? Perhaps by looking at the domains in scope after generalization? For me, the answers to questions a-c are also not clear yet for Michael's current proposal. Paul Prescod
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]