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] Comments on LwDITA Committee Note (and a couple of Leigh's comments)


It is allowed to have an element that is a specialization of another element but not allow the base element in your document. This constitutes a constraint and needs to be declared, but it doesn’t require an actual constraint module (at least for DTDs) because the elimination of the base element is done as part of the domain integration in the DTD shell (i.e., you simply don’t include the base element in the base element’s domain integration parameter entity. The @class attribute value would always show the specialization hierarchy.

Or said another way: the @class value has nothing to do with what is or isn’t included in a given DITA document type, it only reflects the specialization hierarchy.

In the case of the multimedia domain, the integration would be:

<!ENTITY % object “audio | video” >

Note that object is omitted, meaning that anywhere %object; is referenced, only audio and video would be allowed.

Cheers,

Eliot

--
Eliot Kimber
http://contrext.com
 


On 6/20/17, 6:33 PM, "Richard Hamilton" <dita@lists.oasis-open.org on behalf of hamilton@xmlpress.net> wrote:

    Here are my notes on the LwDITA document. I also inserted a couple of points and a question for the group on Leigh’s comments, which are quoted below. All of these notes are from my perspective as a user of DITA who is not an expert in the schema. I’ll also try not to duplicate comments from others too much.
    
    General notes: 
    
    - Thanks to everyone who worked on this document; it clearly shows a lot of care.
    
    - The document mentions several times (e.g., pages 8 and 11) that the committee considered the needs of various constituencies. It would make the point more powerfully if you could name/thank people in those communities who contributed input or reviewed this work.
    
    - I presume that the use of DTDs, rather than RelaxNG, which is normative for 1.3, is merely a convenience in the short run, and that the final version will be RNG. Is that correct?
    
    Page-by-page notes:
    
    Page 8: I don't think you need the first paragraph. It doesn't add anything, and when I read it, my initial thought was that the first sentence is a poster child for why you should avoid passive voice:-). 
    
    Page 9: Leigh’s comment:
    > 
    > 3 What is Lightweight DITA? -- Last bullet
    > LW: Should be a level-2 bullet?
    
    I think it should be a level-1 bullet, though it may be better to place it somewhere other than at the end of the list.
    
    Page 10: It’s not clear to me from the description in the third paragraph whether using the extended profile renders MDITA fully compatible with HDITA and XDITA or if there are other limitations. I’m guessing the latter, based on notes in other places (e.g., page 13 concerning conref), but it’s not clear here.
    
    Page 16: Leigh’s comment:
    > 
    > Page 16 -- "All XDITA topics are designed to be fully compatible with DITA 1.3 topics."
    > LW: A bit misleading? I think it will be a very common scenario to have LwDITA topics alongside standard DITA topics in a standard ditamap. These multimedia elements are a glitch in that scenario in that they are not present in standard DITA and impede complete compatibility. What is the recommendation? That groups specialize these elements from <object> in their standard DITA DTDs, just as they have been specialized in LwDITA?
    > 
    
    This may just reflect my relative ignorance of DITA, but as I understand it, the LwDITA schema does not include <object>, but it does include multimedia elements that are specialized from <object> and which do not exist in DITA 1.3.
    
    If that’s correct, then isn’t it the case that the class attribute for the multimedia elements can’t show the inheritance or those elements wouldn’t validate with the LwDITA schema? However, if the class attribute doesn’t show the inheritance, if you combine an LwDITA topic with a DITA 1.3 document, it will not validate under 1.3. Seems like a Catch 22.
    
    Page 23: I like the table showing the three markup languages; that really helps make this concrete.
    
    Page 23+: I’m not sure how HDITA can be fully compatible with XDITA when it has so many “Not applicable” components (dlentry, navtitle, topicmeta, and underline). For example, I don’t see how you could convert Example 5.1.3 to HDITA and back to XDITA without losing information.
    
    Best regards,
    Dick
    -------
    XML Press
    XML for Technical Communicators
    http://xmlpress.net
    hamilton@xmlpress.net
    
    
    
    
    ---------------------------------------------------------------------
    To unsubscribe from this mail list, you must leave the OASIS TC that
    generates this mail.  Follow this link to all your TCs in OASIS at:
    https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    
    
    




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