<commit_before>/*
 * SIP Communicator, the OpenSource Java VoIP and Instant Messaging client.
 *
 * Distributable under LGPL license.
 * See terms of license at gnu.org.
 */
package net.java.sip.communicator.service.protocol;

import java.net.*;
import java.util.*;

/**
 * The ServerStoredDetails class contains a relatively large set of details that
 * various protocols may support storing online. Each detail is represented by
 * its own inner class that could be instantiated by either the protocol
 * provider implementation (for representing details returned by the server) or
 * by the using service (e.g. the UIService, when representing details that the
 * local user would like to set for the current account).
 * <p>
 * All detail classes inherit from the GenericDetail class, extending it to
 * represent more and more concrete details. The WorkAddressDetail for example,
 * meant to represent a postal work address, extends the AddressDetailClass
 * which is meant for representing all kinds of postal addresses. The
 * AddressDetailClass on its turn extends the StringDetail which itself inherits
 * from the GenericDetailClass.
 * <p>
 * When creating details that do not exist here (which you'll probably have to
 * do at one point or another) you are encouraged to extend from the most
 * concrete address possible so that your detail could be meaningfully handled
 * by the User Interface.
 * <p>
 * Let's assume for example that we'd like to add a BirthPlaceAddressDetail,
 * indicating place of birth. The BirthPlaceAddress detail class should extend
 * the AddressDetail class so that the GUI could understand that this is an
 * address and visualize it appropriately. The same goes for variations of an
 * EmailAddressDetail or any other detail having anything to do with a detail
 * represented in this class.
 * <p>
 * All details have a detailValue and a displayName as well as get methods that
 * would give you (read-only) access to them. Most classes extending the
 * GenericDetail to something more meaningful would provide additional accessors
 * allowing you to retrieve the value casted to its native class.
 * <p>
 * Detail names may be used when visualizing the detail (however, keep in mind
 * that you should leave space for internationalization when doing so).
 * <p>
 * This class is meant for usage with the  OperationSetServerStoredAccountInfo
 * and OperationSetServerStoredUserInfo operation sets.
 *
 * @author <NAME>
 */
public class ServerStoredDetails
{
    /**
     * A generic detail used as the root of all other server stored details.
     * This class should be extended or instantiated by implementors with the
     * purpose of representing details not defined here.
     */<commit_msg>Fixed javadocs<commit_after>/*
 * SIP Communicator, the OpenSource Java VoIP and Instant Messaging client.
 *
 * Distributable under LGPL license.
 * See terms of license at gnu.org.
 */
package net.java.sip.communicator.service.protocol;

import java.net.*;
import java.util.*;

/**
 * The ServerStoredDetails class contains a relatively large set of details that
 * various protocols may support storing online. Each detail is represented by
 * its own inner class that could be instantiated by either the protocol
 * provider implementation (for representing details returned by the server) or
 * by the using service (e.g. the UIService, when representing details that the
 * local user would like to set for the current account).
 * <p>
 * All detail classes inherit from the GenericDetail class, extending it to
 * represent more and more concrete details. The WorkAddressDetail for example,
 * meant to represent a postal work address, extends the AddressDetailClass
 * which is meant for representing all kinds of postal addresses. The
 * AddressDetailClass on its turn extends the StringDetail which itself inherits
 * from the GenericDetailClass.
 * <p>
 * When creating details that do not exist here (which you'll probably have to
 * do at one point or another) you are encouraged to extend from the most
 * concrete address possible so that your detail could be meaningfully handled
 * by the User Interface.
 * <p>
 * Let's assume for example that we'd like to add a BirthPlaceAddressDetail,
 * indicating place of birth. The BirthPlaceAddress detail class should extend
 * the AddressDetail class so that the GUI could understand that this is an
 * address and visualize it appropriately. The same goes for variations of an
 * EmailAddressDetail or any other detail having anything to do with a detail
 * represented in this class.
 * <p>
 * All details have a detailValue and a displayName as well as get methods that
 * would give you (read-only) access to them. Most classes extending the
 * GenericDetail to something more meaningful would provide additional accessors
 * allowing you to retrieve the value casted to its native class.
 * <p>
 * Detail names may be used when visualizing the detail (however, keep in mind
 * that you should leave space for internationalization when doing so).
 * <p>
 * This class is meant for usage with the  OperationSetServerStoredAccountInfo
 * and OperationSetServerStoredContactInfo operation sets.
 *
 * @author <NAME>
 */
public class ServerStoredDetails
{
    /**
     * A generic detail used as the root of all other server stored details.
     * This class should be extended or instantiated by implementors with the
     * purpose of representing details not defined here.
     */
{'fraction_non_alphanumeric': 0.04886943836615609, 'fraction_numerical': 0.0, 'mean_word_length': 4.135767790262173, 'pattern_counts': {'":': 0, '<': 17, '<?xml version=': 0, '>': 17, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1920048', 'n_tokens_mistral': 1306, 'n_tokens_neox': 1271, 'n_words': 751}