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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-users message

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


Subject: Re: Implementing a constraint against the DITA 1.3 RNG implementation


Hello Dita-Users --

I asked this a few weeks ago; let's try with some more detail.

The goal is to constrain the definition of the <li> element in base DITA, so that any subsequent use of domains will respect the constrained definition.  The desired constraint is for <li> to have a content model of <p> (or maybe <p>+).  We don't want to edit the actual OASIS DITA base schemas.

So far as I can tell, editing the OASIS base schema is the only option.  RNG allows one and only one definition of a thing, and allows you to replace definitions inside <include> statements but does NOT allow include-in-include, so there's no way to say "these are our changes, use them several places"; the replacement definitions must be explicitly present in each include where you want to see a change made by this mechanism.  There is no RNG equivalent of the DTD "multiple entity definitions for the same entity are fine, we follow rules to decide when one applies".

If we give up, accept that we must change the base schemas, and edit topicMod.rng 

<include href="">
      <a:documentation>Content elements common to map and topic</a:documentation>
  <define name="li.content">
   <ref name="p.element" />
  </define>
    </include>

We can replace the content model for the list item element, but ONLY if we edit the actual base schema definition.

Directly editing the base seems like a terrible idea; in part for all the usual information-hiding software best practices, in part because this introduces a "is this really DITA?" testing problem, and in part because some existing domains presume the base definition but do not necessarily explicitly reference it.

Is it the expected best practice that, yup, you have to edit the base schemas to get a constraint?   If that is the case, is there a reason to prefer replace-in-includes to directly changing the definitions?  (Directly changing the definitions seems to leave a lot more scope for commenting out the base version and leaving it in place as documentation.)

If not -- no, you are NOT expected to edit the base! -- how do you get a base element constraint in an RNG schema?

thanks!
Graydon


Graydon Saunders | Publishing Solutions Developer | Precision Content 
Direct: +1
 (647)265-8500 x106Email: graydon@precisioncontent.com | www.precisioncontent.com

 


 

Unlock the Knowledge in Your Enterprise™


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. ©2019, Precision Content Authoring Solutions Inc, Mississauga, Ontario, Canada


From: Graydon Saunders
Sent: 02 July 2019 13:29
To: dita-users@lists.oasis-open.org <dita-users@lists.oasis-open.org>
Subject: Implementing a constraint against the DITA 1.3 RNG implementation
 

Hello --


Using the RNG implementation of the DITA 1.3 standard, I want to constrain the li element so that its content model permits only a p element.  I want to do this in such a way that as domain specializations are added to document definitions, those domain specializations will acquire this constraint without any further changes being required.

 

How should I do this?


Thanks!



Graydon Saunders | Publishing Solutions Developer | Precision Content 
Direct: +1
 (647)265-8500 x106Email: graydon@precisioncontent.com | www.precisioncontent.com

 


 

Unlock the Knowledge in Your Enterprise™


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Please notify us by return email if you have received this email in error. ©2019, Precision Content Authoring Solutions Inc, Mississauga, Ontario, Canada



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