OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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:

  1. Why wouldn’t we write the trademarking tool in specialization-aware XSLT or Python or Java?
  2. 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]