Loading ...
Sorry, an error occurred while loading the content.

RE: [dita-users] Re: Specialization: wholes in class attribute

Expand Messages
  • ext-auriel.n.manolson@nokia.com
    Thank again Erik again for your prompt reply. I just want to now try to correlate your answers to my two initial questions, make sure we have now fully
    Message 1 of 9 , Sep 6, 2004
    • 0 Attachment
      Thank again Erik again for your prompt reply.
       
      I just want to now try to correlate your answers to my two initial questions, make sure we have now fully understood this properly, and raise one possible issue.
       
      If I understood correctly, your answer to,
      > 1) ... If package Z specializes package Y which specializes package X,
      >
      should all elements in Z specialize elements in Y, or can they
      > directly
      specialize elements in X ?
      was, that an element "ez" in Z may directly specialize an element "ex" in X. (even if "ex" has no specialization in Y)
       
      ... however, based on your  answer to the second question,
      the class attribute of "ez" in Z must never the less always include an entry for package Y.
      a "virtual element" as you called it.
       
      ei. "+ X/ex Y/ex Z/ez" even though there is no such element with class attribute "+ X/ex Y/ex"
      (and you explained the reason why fairly clearly)
       
      Ok, that summarizes what I think is now fairly clearly understood.
       
      Now, assuming we are still working with DTDs.
       
      let us consider a case where say, an element "section" does exist in packY that specializes packX/section, and whose class is thus attribute "+ packX/section packY/section", as well as the case of the element "ex" above.
       
      An author writing a document using packY, could insert the element "ex" and it would have a class attribute "+ packX/ex".
       
      However, a document authored in packZ, and "dumbed down " to packY would contain the same element, but now with a class attribute "+ packX/ex packY/ex", of course if the document was further edited in packY, additional "ex" elements would again have the class attribute "+ packX/ex", thus presenting a discrepancy in the class attribute used for same element within packY, and even within a single instance.
       
      In the case of the "section" element, there is of course no discrepancy, and the "packY/section" component of the class attribute has a significance as well.
       
      Now I don't know if having such discrepancy causes any problems per se, but it does feel a little concerning and wanted to bring this up.
       
      Of course this could be avoided if
          A) every packY had to "specialize" using the same name (i.e. just add the packY/element to the class attribute", every element it inherited from packX which is valid within it's content models. (in other words, if you answered the opposite to my initial Question 1)
          B) the "dumb down" process was smart enough to recognize the "whole" in the chain.
          i.e.. when "dumbing down" from packZ to packY "+ packX/ex packZ/ez" would get dumbed down to "ex" in packY with class attribute  "+ packX/ex" (in other words, if you answered the opposite to my initial Question 2)
       
      Now I have assumes we are working with DITA DTDs, I do not know if this is somehow different if we are working with Schemas instead.
       
       
      Shall we allow discrepancy in class attributes for the same elements?
      Any comments / thoughts?
       
      best regards,
          Auriel Manolson.
       
    • ehennum5
      ... questions... ... class attribute + X/ex Y/ex Yes, this is correct. ... The initial DITA designers shared your discomfort with the potential ambiguity.
      Message 2 of 9 , Sep 7, 2004
      • 0 Attachment
        Hi, Auriel:

        --- In dita-users@yahoogroups.com, <ext-auriel.n.manolson@n...> wrote:
        > ...
        > I just want to now try to correlate your answers to my two initial
        questions...
        >
        > ... ei. "+ X/ex Y/ex Z/ez" even though there is no such element with
        class attribute "+ X/ex Y/ex"

        Yes, this is correct.

        > Now, assuming we are still working with DTDs.
        >
        > let us consider a case where say, an element "section" does
        > exist in packY that specializes packX/section, and whose class
        > is thus attribute "+ packX/section packY/section", as well as the
        > case of the element "ex" above.

        The initial DITA designers shared your discomfort with the potential
        ambiguity.

        For that reason, in current DITA, an element name has to be unique
        across all specialization modules (aka packages) that are in the
        vocabulary including base module dependencies.

        Otherwise, when looking at the section element, a process wouldn't be
        able to determine the specialization module to which the element
        belongs. Similar, a validating XML editor wouldn't be able to
        determine which content model or attribute list to apply.

        So, you'd need to have something like

        "+ packX/xSection packY/ySection "

        where x and y are disambiguating prefixes for the section element.

        These disambiguating prefixes serve a similar role to namespace
        prefixes (only without the colon or the binding to a scoping URI).

        On this subject, while DITA doesn't use namespaces now to distinguish
        specialization modules, it's _possible_ that DITA will incorporate
        namespaces into the specialization design pattern in the future
        precisely to handle issues like the one you raise. The OASIS Technical
        Committee would have to work through the issues, however, and get
        confidence in a scheme.

        So, currently, "+ packX/section packY/section ..." would be possible
        only if section does _not_ exist in packY.


        Hoping that's useful,


        Erik Hennum
      • ext-auriel.n.manolson@nokia.com
        Thanks again Erik. I think this pretty much clears everything up, and I believe you are pretty clear when you say... ... ... but I just want to make 100% sure
        Message 3 of 9 , Sep 8, 2004
        • 0 Attachment
          Thanks again Erik.

          I think this pretty much clears everything up, and I believe you are pretty clear when you say...

          > For that reason, in current DITA, an element name has to be unique
          > across all specialization modules (aka packages) that are in the
          > vocabulary including base module dependencies.
          ...
          > So, you'd need to have something like
          > "+ packX/xSection packY/ySection "
          > where x and y are disambiguating prefixes for the section element.

          ... but I just want to make 100% sure we are talking about the element itself being called ySection, not just the class attribute, correct?

          best regards,
          Auriel Manolson.
        • ehennum5
          Hi, Ariel: Thanks for driving the conversation toward precision. In particular... ... element itself being called ySection, not just the class attribute,
          Message 4 of 9 , Sep 8, 2004
          • 0 Attachment
            Hi, Ariel:

            Thanks for driving the conversation toward precision.

            In particular...

            --- In dita-users@yahoogroups.com, <ext-auriel.n.manolson@n...> wrote:
            > ... but I just want to make 100% sure we are talking about the
            element itself being called ySection, not just the class attribute,
            correct?

            Yes. When expressed in the packY specialization module, the document
            instance (including the defaulted class attribute) would resemble

            <ySection class="+ topic/section packX/xSection packY/ySection ">
            ...
            </ySection>

            When generalized to the packX specialization module, the document
            instance would resemble

            <xSection class="+ topic/section packX/xSection packY/ySection ">
            ...
            </xSection>

            When generalized to base topic:

            <section class="+ topic/section packX/xSection packY/ySection ">
            ...
            </section>

            A footnote -- I added the topic/section element because all
            specialized elements have to have an element in the topic module as
            their ultimate ancestor.


            Hoping that's confirmational,


            Erik Hennum
          Your message has been successfully submitted and would be delivered to recipients shortly.