That works for me too - though given the only
theoretical utility of roundtripping, I'd prefer a more easily parsed
option as well.
Again, why not an empty parameter entity (dtd) and attribute group
(schema) that you could put anything in all all, and which would be
discarded on generalization?
Attributes should actually be easier to specialize than elements, not
harder: there's no content model to enforce. So why not throw them wide
open? Generic processing can simply ignore the additions.
--Dana
Michael Priestley wrote:
I was thinking roughly the same
thing,
although perhaps with "meta" as the generic ancestor, parallel
with "props". If we are willing to restrict the normal
content of "meta" to be simple tokens (ie simply don't allow
parentheses except in the generalized form) then we could use the exact
same model for generalizing/roundtripping both attributes. Effectively
we'd have one generic ancestor attribute for conditional processing
attributes,
and one for anything else. They could also share the same XSLT library
for unpacking the conditions if processing is desired in the
generalized
form (any process that can't handle the generalized form would be
considered
specialization-unaware).
Michael Priestley
mpriestl@ca.ibm.com
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
|