Yes, but as I said, attributes are less constraining than elements, and
should be even easier to add.
And I can tell you that I for sure need to add CDATA attributes - and I
suppose if I do, many others do too - and will continue to push for a
customization hook in the dtd/schema if we can't find a way to parse
them into a generalizable form.
If we can find a way - then the addition of an authorized customization
hook is a dead issue.
Michael Priestley wrote:
The key statement below is "like
you can with elements". In fact you cannot add arbitrary elements
in DITA, they must be based on existing elements, which is exactly what
we're proposing for attributes. So it's not completely arbitrary, just
arbitrary enough :-)
The one place we've seen a
consistent
requirement for new attributes, by the way, is for new profiling
attributes
(what get called metadata attributes in the spec). I'm betting that's
what
the author below was referring to.
Michael Priestley
mpriestl@ca.ibm.com
Okay, I understand (theoretically) the
ambition
to make specialization something more than just an easy way to
customize.
But what's wrong with providing both? Why shouldn't DITA be easy
to customize, where customization is application specific and willing
to
be ignored everywhere else?
And I think making DITA easier to customize with respect to attributes
is a big deal to the community of potential users - the following from
another list I'm on where someone asked people to summarize their take
on DITA:
* What is the worst thing about using DITA?
-- You have to break DITA (or add to it) to do anything useful with
attributes. The DITA committee is developing a solution to this right
now.
The problem is that you can't add arbitrary attributes like you can with
elements.
Michael Priestley wrote:
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
mpriestl@ca.ibm.com
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
|