It would be accomplished using an entity
redefinition, same as with domains.
I think the theoretical advantages are
substantial. Under the current model, specialization modules are plug and
play: we can determine by inspecting the class and domains attributes what
modules are needed for a document type, compare constraints/modules across
document types, automatically determine lowest common denomenators between
different document types, and generally make information exchange possible
on an automatic level across document type boundaries.
If we allow attributes to be part of
a specific custom DTD, not part of a specialization, then we los the ability
to move that information up the framework or identify which attributes
have been added. Instead of having a document type that follows consistent
rules that can be automatically compared and ultimately automatically assembled,
we have a custom DTD that must be built by hand, customized by hand, and
migrated by hand. In other words it no longer operates as part of a framework,
because something outside the framework has its hooks in it.
If you view specialization as just a
way to make customization easier, what you're saying makes sense. But specialization
isa lot more than that. The advantages of specialization, as described
above, are based on thought experiments rather than experience simply because
DITA is in its early days and there are only a few dozen specializations
floating around, at different levels of completeness and at different companies.
But if you follow the thought experiment forward, and think of what happens
when we have hundreds of specializations across industries and authoring
communities and want to manage the differences and commonalities in a consistent
and scalable way, specialization delivers what customization cannot: a
way to automatically inspect, compare, and reconcile those differences
without loss of information or loss of processing capability.
Michael Priestley
Dana Spradley <>
08/02/2005 04:08 PM
To
cc
Subject
Re: [dita] Proposal for generalized
attribute addition
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
"Paul Prescod"
<>
08/02/2005 03:41 PM
To
<>
cc
Subject
[dita] 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
