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] Stage one proposal: Changes to indexing

I agree with Kris' and Robert's analysis. Index-term, index-see, and index-see-also, along with sort-as, are (almost) the complete universe of indexing elements. 

The only non-met indexing requirement I can think of is a direct TC-defined way to indicate that a given index-term instance is the primary entry for a term. But I don't think it's worth adding a new domain just for this one element, which would be a specialization of index-term. Alternatively, we could simply add a new attribute to index-term, @is-primary, if desired.

Index-base as a specialization base is not really very useful because it doesn't tell you anything actionable about its specializations except that they are involved in indexing *in some way*, but except for simply not rendering them at the point of occurrence, there's no common semantic that can be applied to index-term, index-see, and index-see-also, so having a common base is not really justified.

By contrast, the lcInteractionBase/lcInteractionBase2 element is essential because knowing that an element is an interaction *of any kind* is quite useful and there is sufficient commonality among all existing (and possible) interactions that there is useful common processing that can be applied to it (for example, getting the interaction label or feedback elements), or simply satisfying the search "find all interactions in my content set".

Index-base and lcInteractionBase are also examples of something I've thought DITA should have always had but I've never thought was worth actually proposing, which is "abstract" types are that are like abstract classes in object-oriented programming, where you are explicitly prohibited from instantiating them. I have no idea how you'd indicate this, perhaps by simply not using the element type in any content models, along with some separate syntax that indicates an abstract, type, something like "^" instead of "-" or "+" at the start of the @class value. In any case, I'm not suggesting this is something we need for DITA 2.0, just pointing out that DITA has element types that are explicitly intended only as specialization bases but no way to make that explicit syntactically, only through prose.


Eliot Kimber

ïOn 6/10/19, 11:14 AM, "Robert D Anderson" <dita@lists.oasis-open.org on behalf of robander@us.ibm.com> wrote:

    I assume this would also allow us to remove <index-base>. It's one of those "only there for specialization" elements, put in so that we could specialize the see + see-also + sort-as elements while adding only one base element. I've never heard of it being used for anything else -- has anybody else?
    Having index-base does (theoretically) let us say "This is only one base element and other things are just domains", Practically though -- if you're not using indexing, you never see any of these elements (because they only show up after you've added an index term). For those who are using indexing, index-base is a confusing element to see, and I've heard that for some it's standard practice to set up constraints to keep it out.
    I like the idea here - I think it simplifies the architecture, gets rid of redundant elements, and (bonus) will make the specification much simpler by letting us describe all of the index functions as a single core part of the spec.
    Robert D Anderson
    IBM Authoring Tools Development
    Chief Architect, DITA Open Toolkit  (http://dita-ot.sourceforge.net/)
    Kristen James Eberlein ---06/08/2019 01:04:29 PM---Back history: <indexterm> was part of DITA 1.0 The indexing domain (<index-see>, <index-see-also>, a
    From:        Kristen James Eberlein <kris@eberleinconsulting.com>
    To:        DITA TC <dita@lists.oasis-open.org>
    Date:        06/08/2019 01:04 PM
    Subject:        [EXTERNAL] [dita] Stage one proposal: Changes to indexing
    Sent by:        <dita@lists.oasis-open.org>
    Back history:
         * <indexterm> was part of DITA 1.0
         * The indexing domain (<index-see>, <index-see-also>, and <index-sort-as>) and <index-base>was introduced in DITA 1.1.
         * In DITA 1.3, we added <sort-as>.
    I want to suggest that we clean this up for DITA 2.0:
         * Remove the indexing domain, and add <index-see> and <index-see-also> to the base
         * Remove <index-sort-as> and just use <sort-as>
    Kristen James Eberlein
    Chair, OASIS DITA Technical Committee
    Principal consultant, Eberlein Consulting
    www.eberleinconsulting.com <http://www.eberleinconsulting.com>
    +1 919 622-1501; kriseberlein (skype)
    --------------------------------------------------------------------- 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]