OASIS Darwin Information Typing Architecture (DITA) TC

 View Only

  • 1.  Conditional processing attribute values - any restrictions?

    Posted 03-18-2025 11:23

    Hi,

    This came up with one of my clients, who had a very long value with some boolean-ish logic built into the value.

    For example:

    <subjectdef keys="(feature=NoMainframeSubsystem_and_(interface=VisualStudioIDE_or_(interface=EclipseIDE_and_platform=UNIX)_or_feature=deployment))_or_feature=DevelopmentHub"/>

    Conditional processing attribute values

    As this value is defined in a subject scheme as a key it must adhere to the naming conditions for keys, but beyond that are there any other restrictions that would need to be highlighted in the docs?

    I understand that the above example may collide with the functionality defined in the following topic where we use "()" for grouping.

    Conditional processing attribute values with groups

    Should we specifically mention any restrictions to conditional attribute values outside of keys restrictions?



    ------------------------------
    Eric Sirois
    Madcap Software - Associate
    ------------------------------


  • 2.  RE: Conditional processing attribute values - any restrictions?

    Posted 03-18-2025 11:28

    Here is the topic where we define restrictions on @keys values 

    Setting key names with the keys attribute



    ------------------------------
    Eric Sirois
    Madcap Software - Associate
    ------------------------------

    Original Message


  • 3.  RE: Conditional processing attribute values - any restrictions?

    Posted 03-18-2025 12:16

    It seems like an oversight that we don't exclude parens from key names but I don't recall our specific discussion on that.

     

    It does seem like parens are implicitly excluded from conditional attribute tokens because it would interfere with the grouping syntax.

     

    I know we wanted to avoid making key names as restrictive as NMTOKEN, thus the language about being limited to characters allowed in URIs. Note that "allowed in URIs" means "characters that don't require escaping".

     

    From RFC 3986, URIs (https://www.ietf.org/rfc/rfc3986.txt):

    "A URI is a sequence of characters from a
       very limited set: the letters of the basic Latin alphabet, digits,
       and a few special characters."

    It further says:

    Reserved Characters
     
       URIs include components and subcomponents that are delimited by
       characters in the "reserved" set.  These characters are called
       "reserved" because they may (or may not) be defined as delimiters by
       the generic syntax, by each scheme-specific syntax, or by the
       implementation-specific syntax of a URI's dereferencing algorithm.
       If data for a URI component would conflict with a reserved
       character's purpose as a delimiter, then the conflicting data must be
       percent-encoded before the URI is formed.
     
          reserved    = gen-delims / sub-delims
     
          gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
     
          sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
                      / "*" / "+" / "," / ";" / "="
     

     

    That is, the reserved characters are reserved for the unescaped delimiter parts of URIs, as opposed to the values of different components (i.e., the resource part or fragment identifier, or whatever).

    Since "(" and ")" are in this list, it suggests that they should also be explicitly disallowed from key names, which makes their omission from the "Setting key names with the @keys attribute" topic an error that we should correct.

     

    We could probably clarify the rules further by saying "characters allowed in URIs outside the set of reserved characters."

     

    Cheers,

     

    E.

    _____________________________________________

    Eliot Kimber

    Sr. Staff Content Engineer

    O: 512 554 9368

     

    servicenow

     

    servicenow.com

    LinkedIn | X | YouTube | Instagram

     




    Original Message


Related Content