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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-adoption message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita-adoption] Groups - Feature Overview: Domain and topic integration (domain_and_topic_integration_v0_2.pdf) uploaded


Hi Paul,

Thank you so much for these comments. I will have a look at these comments and suggestions and incorporate them in the next version. 

Re the distinction between "base topic elements" and "common base module elements" the names was taken from the architectural spec (1.1) but I agree that is confusing. I wanted to illustrate that in DITA 1.1 a domain can only specialize the base content elements at the top-level topic and not the topic elements (like <topic>, <body>). I will go to the spec again to see  if I can come up with a better way to make the distinction.

I will get back to you on the other points later this week.

Best regards,
Marc
>-----Original Message-----
>From: Grosso, Paul [mailto:pgrosso@ptc.com]
>Sent: Tuesday, November 24, 2009 9:17 PM
>To: dita-adoption@lists.oasis-open.org
>Subject: RE: [dita-adoption] Groups - Feature Overview: Domain and topic
>integration (domain_and_topic_integration_v0_2.pdf) uploaded
>
>
>> -----Original Message-----
>> From: m.y.speyer@inter.nl.net [mailto:m.y.speyer@inter.nl.net]
>> Sent: Thursday, 2009 November 12 10:20
>> To: dita-adoption@lists.oasis-open.org
>> Subject: [dita-adoption] Groups - Feature Overview: Domain and topic
>> integration (domain_and_topic_integration_v0_2.pdf) uploaded
>>
>> Hello everyone,
>>
>> Please find an first draft of the article on Feature #12010: Domain and
>> topic integration.
>
>Here are the comments I received from another reviewer.
>
>
>This point:
>Domain specialization creates new markup for use in structural types, such
>as new kinds of keywords, tables, or lists, or new attributes such as
>conditional processing attributes
>
>would be better as
>
>Domain specializations create new markup for use in many structural types,
>such as new kinds of keywords, tables, or lists, or new conditional
>processing attributes.
>
>---
>
>In the first table, what are “common base module elements” and how are they
>different from “base topic elements”?
>
>---
>
>In example 1 “a special specific user interface” might be better as “a
>specific user interface” or “special user interface”.
>
>---
>
>proper vs. properly
>
>---
>
>In the 2nd table, should “common base module elements” be “base topic
>elements”?
>
>Still in the 2nd table, I’m not sure why the “ui domain” is in the top row
>rather than in the middle or bottom row.
>
>Still in the 2nd table, is “task topic” really “task specialization”?
>
>Still in the 2nd table, is “uiTask topic” really “new uiTask
>specialization”?
>
>---
>
>For this example do they really need a new uiTask specialization? It seems
>as if this could just be done using a domain specialization and including
>uiTask implies that it is needed for some reason.
>
>---
>
>There are two example 2s.
>
>---
>
>In example 4 I’m not sure what the point of having the uiReference topic is.
>
>---
>
>I don’t think that the article makes a good distinction between what
>can/must be done in a DITA document type shell and what can be done in a
>specialization module, but perhaps that isn’t necessary.
>
>---
>
>They could probably remove the whole section that gives the detailed steps
>about how to make a new specialization without any loss of information.  Do
>people reading this article really need to know about the entity
>declarations?
>
>---
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]