MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] The trademarking tool
If writing the XSLT 1.0 code for parsing
generalized CDATA attributes is a problem, I would be also be glad to
help.
--Dana
Paul Prescod wrote:
Questions
about respecialization:
- Why wouldn’t we write the
trademarking tool in specialization-aware XSLT or Python or Java?
- If the trademarking tool
validates the input and output against the generalized DTD/schema,
isn’t there a danger that the content does not validate against the
specialized one anymore?
When I
thought through these issues in the
architectural forms context I came to the conclusion that all document
modifications should be done in the most specialized view. Working with
generalized content is only “safe” for read-only applications.
That said,
I’m not a purist. If
someone wants to do something unsafe in their environment then that’s
their call. But by the same token, if Dana wants to unsafely add
specialization-lossy
attributes to his doctype then I don’t think that there is any reason
to
stop him.
I think that
it is inevitable that people
WILL add attributes (including CDATA and URL attributes) because no
DITA
authoring tool or validator will complain if they do so. CMS vendors
have
already told me that the intend to add attributes for tracking object
IDs
(which may be paths or URLs). If respecialization is important then we
need to
make it work with this common use case. If it isn’t important then it
shouldn’t stand in the way of the use case.
Would it
help if I wrote the XSLT 1.0 code
to parse generalized attributes?
Paul Prescod
|
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]