001/* ----------------------------------------------------------------------------
002 * This file was automatically generated by SWIG (http://www.swig.org).
003 * Version 3.0.12
004 *
005 * Do not make changes to this file unless you know what you are doing--modify
006 * the SWIG interface file instead.
007 * ----------------------------------------------------------------------------- */
008
009package org.sbml.libsbml;
010
011/** 
012 *  A <em>compartment type</em> in SBML Level&nbsp;2.
013 <p>
014 * SBML Level&nbsp;2 Versions&nbsp;2&ndash;4 provide the <em>compartment
015 * type</em> as a grouping construct that can be used to establish a
016 * relationship between multiple {@link Compartment} objects.  A {@link CompartmentType}
017 * object only has an identity, and this identity can only be used to
018 * indicate that particular {@link Compartment} objects in the model belong to this
019 * type.  This may be useful for conveying a modeling intention, such as
020 * when a model contains many similar compartments, either by their
021 * biological function or the reactions they carry.  Without a compartment
022 * type construct, it would be impossible within SBML itself to indicate
023 * that all of the compartments share an underlying conceptual relationship
024 * because each SBML compartment must be given a unique and separate
025 * identity.  A {@link CompartmentType} has no mathematical meaning in
026 * SBML&mdash;it has no effect on a model's mathematical interpretation.
027 * Simulators and other numerical analysis software may ignore
028 * {@link CompartmentType} definitions and references to them in a model.
029 <p>
030 * There is no mechanism in SBML Level 2 for representing hierarchies of
031 * compartment types.  One {@link CompartmentType} instance cannot be the subtype
032 * of another {@link CompartmentType} instance; SBML provides no means of defining
033 * such relationships.
034 <p>
035 * As with other major structures in SBML, {@link CompartmentType} has a mandatory
036 * attribute, 'id', used to give the compartment type an identifier.  The
037 * identifier must be a text string conforming to the identifer syntax
038 * permitted in SBML.  {@link CompartmentType} also has an optional 'name'
039 * attribute, of type <code>string.</code>  The 'id' and 'name' must be used
040 * according to the guidelines described in the SBML specification (e.g.,
041 * Section 3.3 in the Level 2 Version 4 specification).
042 <p>
043 * {@link CompartmentType} was introduced in SBML Level 2 Version 2.  It is not
044 * available in SBML Level&nbsp;1 nor in Level&nbsp;3.
045 <p>
046 * @see Compartment
047 * @see ListOfCompartmentTypes
048 * @see SpeciesType
049 * @see ListOfSpeciesTypes
050 */
051
052public class CompartmentType extends SBase {
053   private long swigCPtr;
054
055   protected CompartmentType(long cPtr, boolean cMemoryOwn)
056   {
057     super(libsbmlJNI.CompartmentType_SWIGUpcast(cPtr), cMemoryOwn);
058     swigCPtr = cPtr;
059   }
060
061   protected static long getCPtr(CompartmentType obj)
062   {
063     return (obj == null) ? 0 : obj.swigCPtr;
064   }
065
066   protected static long getCPtrAndDisown (CompartmentType obj)
067   {
068     long ptr = 0;
069
070     if (obj != null)
071     {
072       ptr             = obj.swigCPtr;
073       obj.swigCMemOwn = false;
074     }
075
076     return ptr;
077   }
078
079  protected void finalize() {
080    delete();
081  }
082
083  public synchronized void delete() {
084    if (swigCPtr != 0) {
085      if (swigCMemOwn) {
086        swigCMemOwn = false;
087        libsbmlJNI.delete_CompartmentType(swigCPtr);
088      }
089      swigCPtr = 0;
090    }
091    super.delete();
092  }
093
094  
095/**
096   * Creates a new {@link CompartmentType} object using the given SBML <code>level</code> and
097   * <code>version</code> values.
098   <p>
099   * @param level a long integer, the SBML Level to assign to this
100   * {@link CompartmentType}.
101   <p>
102   * @param version a long integer, the SBML Version to assign to this
103   * {@link CompartmentType}.
104   <p>
105   * <p>
106 * @throws SBMLConstructorException
107 * Thrown if the given <code>level</code> and <code>version</code> combination are invalid
108 * or if this object is incompatible with the given level and version.
109   <p>
110   * <p>
111 * @note Attempting to add an object to an {@link SBMLDocument} having a different
112 * combination of SBML Level, Version and XML namespaces than the object
113 * itself will result in an error at the time a caller attempts to make the
114 * addition.  A parent object must have compatible Level, Version and XML
115 * namespaces.  (Strictly speaking, a parent may also have more XML
116 * namespaces than a child, but the reverse is not permitted.)  The
117 * restriction is necessary to ensure that an SBML model has a consistent
118 * overall structure.  This requires callers to manage their objects
119 * carefully, but the benefit is increased flexibility in how models can be
120 * created by permitting callers to create objects bottom-up if desired.  In
121 * situations where objects are not yet attached to parents (e.g.,
122 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
123 * libSBML determine such things as whether it is valid to assign a
124 * particular value to an attribute.
125   */ public
126 CompartmentType(long level, long version) throws org.sbml.libsbml.SBMLConstructorException {
127    this(libsbmlJNI.new_CompartmentType__SWIG_0(level, version), true);
128  }
129
130  
131/**
132   * Creates a new {@link CompartmentType} object using the given {@link SBMLNamespaces}
133   * object <code>sbmlns</code>.
134   <p>
135   * <p>
136 * The {@link SBMLNamespaces} object encapsulates SBML Level/Version/namespaces
137 * information.  It is used to communicate the SBML Level, Version, and (in
138 * Level&nbsp;3) packages used in addition to SBML Level&nbsp;3 Core.  A
139 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an
140 * {@link SBMLNamespaces} object somewhere in a program once, then hand that object
141 * as needed to object constructors that accept {@link SBMLNamespaces} as arguments.
142   <p>
143   * It is worth emphasizing that although this constructor does not take an
144   * identifier argument, in SBML Level&nbsp;2 and beyond, the 'id'
145   * (identifier) attribute of a {@link CompartmentType} object is required to have a
146   * value.  Thus, callers are cautioned to assign a value after calling this
147   * constructor.  Setting the identifier can be accomplished using the
148   * method setId(String).
149   <p>
150   * @param sbmlns an {@link SBMLNamespaces} object.
151   <p>
152   * <p>
153 * @throws SBMLConstructorException
154 * Thrown if the given <code>sbmlns</code> is inconsistent or incompatible
155 * with this object.
156   <p>
157   * <p>
158 * @note Attempting to add an object to an {@link SBMLDocument} having a different
159 * combination of SBML Level, Version and XML namespaces than the object
160 * itself will result in an error at the time a caller attempts to make the
161 * addition.  A parent object must have compatible Level, Version and XML
162 * namespaces.  (Strictly speaking, a parent may also have more XML
163 * namespaces than a child, but the reverse is not permitted.)  The
164 * restriction is necessary to ensure that an SBML model has a consistent
165 * overall structure.  This requires callers to manage their objects
166 * carefully, but the benefit is increased flexibility in how models can be
167 * created by permitting callers to create objects bottom-up if desired.  In
168 * situations where objects are not yet attached to parents (e.g.,
169 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
170 * libSBML determine such things as whether it is valid to assign a
171 * particular value to an attribute.
172   */ public
173 CompartmentType(SBMLNamespaces sbmlns) throws org.sbml.libsbml.SBMLConstructorException {
174    this(libsbmlJNI.new_CompartmentType__SWIG_1(SBMLNamespaces.getCPtr(sbmlns), sbmlns), true);
175  }
176
177  
178/**
179   * Copy constructor; creates a copy of this {@link CompartmentType} object.
180   <p>
181   * @param orig the object to copy.
182   */ public
183 CompartmentType(CompartmentType orig) throws org.sbml.libsbml.SBMLConstructorException {
184    this(libsbmlJNI.new_CompartmentType__SWIG_2(CompartmentType.getCPtr(orig), orig), true);
185  }
186
187  
188/**
189   * Creates and returns a deep copy of this {@link CompartmentType} object.
190   <p>
191   * @return the (deep) copy of this {@link CompartmentType} object.
192   */ public
193 CompartmentType cloneObject() {
194    long cPtr = libsbmlJNI.CompartmentType_cloneObject(swigCPtr, this);
195    return (cPtr == 0) ? null : new CompartmentType(cPtr, true);
196  }
197
198  
199/**
200   * Returns the value of the 'id' attribute of this {@link CompartmentType}.
201   <p>
202   * @note Because of the inconsistent behavior of this function with 
203   * respect to assignments and rules, it is now recommended to
204   * use the getIdAttribute() function instead.
205   <p>
206   * <p>
207 * The identifier given by an object's 'id' attribute value
208 * is used to identify the object within the SBML model definition.
209 * Other objects can refer to the component using this identifier.  The
210 * data type of 'id' is always <code>SId</code> or a type derived
211 * from that, such as <code>UnitSId</code>, depending on the object in 
212 * question.  All data types are defined as follows:
213 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
214 *   letter .= 'a'..'z','A'..'Z'
215 *   digit  .= '0'..'9'
216 *   idChar .= letter | digit | '_'
217 *   SId    .= ( letter | '_' ) idChar*
218 * </pre>
219 <p>
220 * The characters <code>(</code> and <code>)</code> are used for grouping, the
221 * character <code>*</code> 'zero or more times', and the character
222 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
223 * determined by an exact character sequence match; i.e., comparisons must be
224 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
225 * <code>SIdRef</code>, and derived types.
226 <p>
227 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
228 * moved to {@link SBase} directly, instead of being defined individually for many
229 * (but not all) objects.  Libsbml has for a long time provided functions
230 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
231 * would fail or otherwise return empty strings if executed on any object 
232 * for which those attributes were not defined.  Now that all {@link SBase} objects 
233 * define those attributes, those functions now succeed for any object with 
234 * the appropriate level and version.
235 <p>
236 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
237 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
238 * functions (though not the setId() or unsetId() functions) would instead 
239 * reference the value of the 'variable' attribute (for the rules and event 
240 * assignments) or the 'symbol' attribute (for initial assignments).  
241 * The {@link AlgebraicRule} fell into this category as well, though because it 
242 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
243 * always return an empty string, and isSetId() would always return <code>false.</code>
244 * For this reason, four new functions are now provided 
245 * (getIdAttribute(), setIdAttribute(String), 
246 * isSetIdAttribute(), and unsetIdAttribute()) that will always
247 * act on the actual 'id' attribute, regardless of the object's type.  The
248 * new functions should be used instead of the old ones unless the old behavior
249 * is somehow necessary.
250 <p>
251 * Regardless of the level and version of the SBML, these functions allow
252 * client applications to use more generalized code in some situations 
253 * (for instance, when manipulating objects that are all known to have 
254 * identifiers).  If the object in question does not posess an 'id' attribute 
255 * according to the SBML specification for the Level and Version in use,
256 * libSBML will not allow the identifier to be set, nor will it read or 
257 * write 'id' attributes for those objects.
258   <p>
259   * @return the id of this {@link CompartmentType}.
260   <p>
261   * @see #getIdAttribute()
262   * @see #setIdAttribute(String sid)
263   * @see #isSetIdAttribute()
264   * @see #unsetIdAttribute()
265   */ public
266 String getId() {
267    return libsbmlJNI.CompartmentType_getId(swigCPtr, this);
268  }
269
270  
271/**
272   * Returns the value of the 'name' attribute of this {@link CompartmentType} object.
273   <p>
274   * <p>
275 * <p>
276 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
277 * moved to {@link SBase} directly, instead of being defined individually for many
278 * (but not all) objects.  Libsbml has for a long time provided functions
279 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
280 * would fail or otherwise return empty strings if executed on any object 
281 * for which those attributes were not defined.  Now that all {@link SBase} objects 
282 * define those attributes, those functions now succeed for any object with 
283 * the appropriate level and version.
284 <p>
285 * The 'name' attribute is
286 * optional and is not intended to be used for cross-referencing purposes
287 * within a model.  Its purpose instead is to provide a human-readable
288 * label for the component.  The data type of 'name' is the type
289 * <code>string</code> defined in XML Schema.  SBML imposes no
290 * restrictions as to the content of 'name' attributes beyond those
291 * restrictions defined by the <code>string</code> type in XML Schema.
292 <p>
293 * The recommended practice for handling 'name' is as follows.  If a
294 * software tool has the capability for displaying the content of 'name'
295 * attributes, it should display this content to the user as a
296 * component's label instead of the component's 'id'.  If the user
297 * interface does not have this capability (e.g., because it cannot
298 * display or use special characters in symbol names), or if the 'name'
299 * attribute is missing on a given component, then the user interface
300 * should display the value of the 'id' attribute instead.  (Script
301 * language interpreters are especially likely to display 'id' instead of
302 * 'name'.)
303 <p>
304 * As a consequence of the above, authors of systems that automatically
305 * generate the values of 'id' attributes should be aware some systems
306 * may display the 'id''s to the user.  Authors therefore may wish to
307 * take some care to have their software create 'id' values that are: (a)
308 * reasonably easy for humans to type and read; and (b) likely to be
309 * meaningful, for example by making the 'id' attribute be an abbreviated
310 * form of the name attribute value.
311 <p>
312 * An additional point worth mentioning is although there are
313 * restrictions on the uniqueness of 'id' values, there are no
314 * restrictions on the uniqueness of 'name' values in a model.  This
315 * allows software applications leeway in assigning component identifiers.
316 <p>
317 * Regardless of the level and version of the SBML, these functions allow
318 * client applications to use more generalized code in some situations 
319 * (for instance, when manipulating objects that are all known to have 
320 * names).  If the object in question does not posess a 'name' attribute 
321 * according to the SBML specification for the Level and Version in use,
322 * libSBML will not allow the name to be set, nor will it read or 
323 * write 'name' attributes for those objects.
324 <p>
325 * @return the name of this SBML object, or the empty string if not set or unsettable.
326 <p>
327 * @see #getIdAttribute()
328 * @see #isSetName()
329 * @see #setName(String sid)
330 * @see #unsetName()
331   */ public
332 String getName() {
333    return libsbmlJNI.CompartmentType_getName(swigCPtr, this);
334  }
335
336  
337/**
338   * Predicate returning <code>true</code> if this {@link CompartmentType} object's 'id'
339   * attribute is set.
340   <p>
341   * <p>
342 * @note Because of the inconsistent behavior of this function with 
343 * respect to assignments and rules, it is now recommended to
344 * use the isSetIdAttribute() function instead.
345 <p>
346 * <p>
347 * The identifier given by an object's 'id' attribute value
348 * is used to identify the object within the SBML model definition.
349 * Other objects can refer to the component using this identifier.  The
350 * data type of 'id' is always <code>SId</code> or a type derived
351 * from that, such as <code>UnitSId</code>, depending on the object in 
352 * question.  All data types are defined as follows:
353 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
354 *   letter .= 'a'..'z','A'..'Z'
355 *   digit  .= '0'..'9'
356 *   idChar .= letter | digit | '_'
357 *   SId    .= ( letter | '_' ) idChar*
358 * </pre>
359 <p>
360 * The characters <code>(</code> and <code>)</code> are used for grouping, the
361 * character <code>*</code> 'zero or more times', and the character
362 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
363 * determined by an exact character sequence match; i.e., comparisons must be
364 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
365 * <code>SIdRef</code>, and derived types.
366 <p>
367 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
368 * moved to {@link SBase} directly, instead of being defined individually for many
369 * (but not all) objects.  Libsbml has for a long time provided functions
370 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
371 * would fail or otherwise return empty strings if executed on any object 
372 * for which those attributes were not defined.  Now that all {@link SBase} objects 
373 * define those attributes, those functions now succeed for any object with 
374 * the appropriate level and version.
375 <p>
376 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
377 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
378 * functions (though not the setId() or unsetId() functions) would instead 
379 * reference the value of the 'variable' attribute (for the rules and event 
380 * assignments) or the 'symbol' attribute (for initial assignments).  
381 * The {@link AlgebraicRule} fell into this category as well, though because it 
382 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
383 * always return an empty string, and isSetId() would always return <code>false.</code>
384 * For this reason, four new functions are now provided 
385 * (getIdAttribute(), setIdAttribute(String), 
386 * isSetIdAttribute(), and unsetIdAttribute()) that will always
387 * act on the actual 'id' attribute, regardless of the object's type.  The
388 * new functions should be used instead of the old ones unless the old behavior
389 * is somehow necessary.
390 <p>
391 * Regardless of the level and version of the SBML, these functions allow
392 * client applications to use more generalized code in some situations 
393 * (for instance, when manipulating objects that are all known to have 
394 * identifiers).  If the object in question does not posess an 'id' attribute 
395 * according to the SBML specification for the Level and Version in use,
396 * libSBML will not allow the identifier to be set, nor will it read or 
397 * write 'id' attributes for those objects.
398 <p>
399 * @return <code>true</code> if the 'id' attribute of this SBML object is
400 * set, <code>false</code> otherwise.
401 <p>
402 * @see #getIdAttribute()
403 * @see #setIdAttribute(String sid)
404 * @see #unsetIdAttribute()
405 * @see #isSetIdAttribute()
406   */ public
407 boolean isSetId() {
408    return libsbmlJNI.CompartmentType_isSetId(swigCPtr, this);
409  }
410
411  
412/**
413   * Predicate returning <code>true</code> if this {@link CompartmentType} object's 'name'
414   * attribute is set.
415   <p>
416   * <p>
417 * <p>
418 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
419 * moved to {@link SBase} directly, instead of being defined individually for many
420 * (but not all) objects.  Libsbml has for a long time provided functions
421 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
422 * would fail or otherwise return empty strings if executed on any object 
423 * for which those attributes were not defined.  Now that all {@link SBase} objects 
424 * define those attributes, those functions now succeed for any object with 
425 * the appropriate level and version.
426 <p>
427 * The 'name' attribute is
428 * optional and is not intended to be used for cross-referencing purposes
429 * within a model.  Its purpose instead is to provide a human-readable
430 * label for the component.  The data type of 'name' is the type
431 * <code>string</code> defined in XML Schema.  SBML imposes no
432 * restrictions as to the content of 'name' attributes beyond those
433 * restrictions defined by the <code>string</code> type in XML Schema.
434 <p>
435 * The recommended practice for handling 'name' is as follows.  If a
436 * software tool has the capability for displaying the content of 'name'
437 * attributes, it should display this content to the user as a
438 * component's label instead of the component's 'id'.  If the user
439 * interface does not have this capability (e.g., because it cannot
440 * display or use special characters in symbol names), or if the 'name'
441 * attribute is missing on a given component, then the user interface
442 * should display the value of the 'id' attribute instead.  (Script
443 * language interpreters are especially likely to display 'id' instead of
444 * 'name'.)
445 <p>
446 * As a consequence of the above, authors of systems that automatically
447 * generate the values of 'id' attributes should be aware some systems
448 * may display the 'id''s to the user.  Authors therefore may wish to
449 * take some care to have their software create 'id' values that are: (a)
450 * reasonably easy for humans to type and read; and (b) likely to be
451 * meaningful, for example by making the 'id' attribute be an abbreviated
452 * form of the name attribute value.
453 <p>
454 * An additional point worth mentioning is although there are
455 * restrictions on the uniqueness of 'id' values, there are no
456 * restrictions on the uniqueness of 'name' values in a model.  This
457 * allows software applications leeway in assigning component identifiers.
458 <p>
459 * Regardless of the level and version of the SBML, these functions allow
460 * client applications to use more generalized code in some situations 
461 * (for instance, when manipulating objects that are all known to have 
462 * names).  If the object in question does not posess a 'name' attribute 
463 * according to the SBML specification for the Level and Version in use,
464 * libSBML will not allow the name to be set, nor will it read or 
465 * write 'name' attributes for those objects.
466 <p>
467 * @return <code>true</code> if the 'name' attribute of this SBML object is
468 * set, <code>false</code> otherwise.
469 <p>
470 * @see #getName()
471 * @see #setName(String sid)
472 * @see #unsetName()
473   */ public
474 boolean isSetName() {
475    return libsbmlJNI.CompartmentType_isSetName(swigCPtr, this);
476  }
477
478  
479/**
480   * Sets the value of the 'id' attribute of this {@link CompartmentType}.
481   <p>
482   * <p>
483 * The string <code>sid</code> is copied.
484 <p>
485 * <p>
486 * The identifier given by an object's 'id' attribute value
487 * is used to identify the object within the SBML model definition.
488 * Other objects can refer to the component using this identifier.  The
489 * data type of 'id' is always <code>SId</code> or a type derived
490 * from that, such as <code>UnitSId</code>, depending on the object in 
491 * question.  All data types are defined as follows:
492 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
493 *   letter .= 'a'..'z','A'..'Z'
494 *   digit  .= '0'..'9'
495 *   idChar .= letter | digit | '_'
496 *   SId    .= ( letter | '_' ) idChar*
497 * </pre>
498 <p>
499 * The characters <code>(</code> and <code>)</code> are used for grouping, the
500 * character <code>*</code> 'zero or more times', and the character
501 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
502 * determined by an exact character sequence match; i.e., comparisons must be
503 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
504 * <code>SIdRef</code>, and derived types.
505 <p>
506 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
507 * moved to {@link SBase} directly, instead of being defined individually for many
508 * (but not all) objects.  Libsbml has for a long time provided functions
509 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
510 * would fail or otherwise return empty strings if executed on any object 
511 * for which those attributes were not defined.  Now that all {@link SBase} objects 
512 * define those attributes, those functions now succeed for any object with 
513 * the appropriate level and version.
514 <p>
515 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
516 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
517 * functions (though not the setId() or unsetId() functions) would instead 
518 * reference the value of the 'variable' attribute (for the rules and event 
519 * assignments) or the 'symbol' attribute (for initial assignments).  
520 * The {@link AlgebraicRule} fell into this category as well, though because it 
521 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
522 * always return an empty string, and isSetId() would always return <code>false.</code>
523 * For this reason, four new functions are now provided 
524 * (getIdAttribute(), setIdAttribute(String), 
525 * isSetIdAttribute(), and unsetIdAttribute()) that will always
526 * act on the actual 'id' attribute, regardless of the object's type.  The
527 * new functions should be used instead of the old ones unless the old behavior
528 * is somehow necessary.
529 <p>
530 * Regardless of the level and version of the SBML, these functions allow
531 * client applications to use more generalized code in some situations 
532 * (for instance, when manipulating objects that are all known to have 
533 * identifiers).  If the object in question does not posess an 'id' attribute 
534 * according to the SBML specification for the Level and Version in use,
535 * libSBML will not allow the identifier to be set, nor will it read or 
536 * write 'id' attributes for those objects.
537 <p>
538 * @param sid the string to use as the identifier of this object.
539 <p>
540 * <p>
541 * @return integer value indicating success/failure of the
542 * function.   The possible values
543 * returned by this function are:
544 * <ul>
545 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
546 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
547 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE}
548 *
549 * </ul> <p>
550 * @see #getIdAttribute()
551 * @see #setIdAttribute(String sid)
552 * @see #isSetIdAttribute()
553 * @see #unsetIdAttribute()
554   */ public
555 int setId(String sid) {
556    return libsbmlJNI.CompartmentType_setId(swigCPtr, this, sid);
557  }
558
559  
560/**
561   * Sets the value of the 'name' attribute of this {@link CompartmentType}.
562   <p>
563   * <p>
564 * The string in <code>name</code> is copied.
565 <p>
566 * @param name the new name for the SBML object.
567 <p>
568 * <p>
569 * @return integer value indicating success/failure of the
570 * function.   The possible values
571 * returned by this function are:
572 * <ul>
573 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
574 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
575 *
576 * </ul>
577   */ public
578 int setName(String name) {
579    return libsbmlJNI.CompartmentType_setName(swigCPtr, this, name);
580  }
581
582  
583/**
584   * Unsets the value of the 'name' attribute of this {@link CompartmentType} object.
585   <p>
586   * <p>
587 * <p>
588 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
589 * moved to {@link SBase} directly, instead of being defined individually for many
590 * (but not all) objects.  Libsbml has for a long time provided functions
591 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
592 * would fail or otherwise return empty strings if executed on any object 
593 * for which those attributes were not defined.  Now that all {@link SBase} objects 
594 * define those attributes, those functions now succeed for any object with 
595 * the appropriate level and version.
596 <p>
597 * The 'name' attribute is
598 * optional and is not intended to be used for cross-referencing purposes
599 * within a model.  Its purpose instead is to provide a human-readable
600 * label for the component.  The data type of 'name' is the type
601 * <code>string</code> defined in XML Schema.  SBML imposes no
602 * restrictions as to the content of 'name' attributes beyond those
603 * restrictions defined by the <code>string</code> type in XML Schema.
604 <p>
605 * The recommended practice for handling 'name' is as follows.  If a
606 * software tool has the capability for displaying the content of 'name'
607 * attributes, it should display this content to the user as a
608 * component's label instead of the component's 'id'.  If the user
609 * interface does not have this capability (e.g., because it cannot
610 * display or use special characters in symbol names), or if the 'name'
611 * attribute is missing on a given component, then the user interface
612 * should display the value of the 'id' attribute instead.  (Script
613 * language interpreters are especially likely to display 'id' instead of
614 * 'name'.)
615 <p>
616 * As a consequence of the above, authors of systems that automatically
617 * generate the values of 'id' attributes should be aware some systems
618 * may display the 'id''s to the user.  Authors therefore may wish to
619 * take some care to have their software create 'id' values that are: (a)
620 * reasonably easy for humans to type and read; and (b) likely to be
621 * meaningful, for example by making the 'id' attribute be an abbreviated
622 * form of the name attribute value.
623 <p>
624 * An additional point worth mentioning is although there are
625 * restrictions on the uniqueness of 'id' values, there are no
626 * restrictions on the uniqueness of 'name' values in a model.  This
627 * allows software applications leeway in assigning component identifiers.
628 <p>
629 * Regardless of the level and version of the SBML, these functions allow
630 * client applications to use more generalized code in some situations 
631 * (for instance, when manipulating objects that are all known to have 
632 * names).  If the object in question does not posess a 'name' attribute 
633 * according to the SBML specification for the Level and Version in use,
634 * libSBML will not allow the name to be set, nor will it read or 
635 * write 'name' attributes for those objects.
636 <p>
637 * <p>
638 * @return integer value indicating success/failure of the
639 * function.   The possible values
640 * returned by this function are:
641 * <ul>
642 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
643 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
644 *
645 * </ul> <p>
646 * @see #getName()
647 * @see #setName(String sid)
648 * @see #isSetName()
649   */ public
650 int unsetName() {
651    return libsbmlJNI.CompartmentType_unsetName(swigCPtr, this);
652  }
653
654  
655/**
656   * Returns the libSBML type code for this SBML object.
657   <p>
658   * <p>
659 * LibSBML attaches an identifying code to every kind of SBML object.  These
660 * are integer constants known as <em>SBML type codes</em>.  The names of all
661 * the codes begin with the characters <code>SBML_</code>.
662 * In the Java language interface for libSBML, the
663 * type codes are defined as static integer constants in the interface class
664 * {@link libsbmlConstants}.    Note that different Level&nbsp;3
665 * package plug-ins may use overlapping type codes; to identify the package
666 * to which a given object belongs, call the 
667 * <code>{@link SBase#getPackageName()}
668 * </code>
669 * method on the object.
670   <p>
671   * @return the SBML type code for this object:
672   * {@link libsbmlConstants#SBML_COMPARTMENT_TYPE SBML_COMPARTMENT_TYPE} (default).
673   <p>
674   * <p>
675 * @warning <span class='warning'>The specific integer values of the possible
676 * type codes may be reused by different libSBML plug-ins for SBML Level&nbsp;3.
677 * packages,  To fully identify the correct code, <strong>it is necessary to
678 * invoke both getTypeCode() and getPackageName()</strong>.</span>
679   <p>
680   * @see #getElementName()
681   * @see #getPackageName()
682   */ public
683 int getTypeCode() {
684    return libsbmlJNI.CompartmentType_getTypeCode(swigCPtr, this);
685  }
686
687  
688/**
689   * Returns the XML element name of this object
690   <p>
691   * For {@link CompartmentType}, the element name is always <code>'compartmentType'.</code>
692   <p>
693   * @return the name of this element.
694   <p>
695   * @see #getTypeCode()
696   * @see #getPackageName()
697   */ public
698 String getElementName() {
699    return libsbmlJNI.CompartmentType_getElementName(swigCPtr, this);
700  }
701
702  
703/**
704   * Predicate returning <code>true</code> if all the required attributes for this
705   * {@link CompartmentType} object have been set.
706   <p>
707   * The required attributes for a {@link CompartmentType} object are:
708   * <ul>
709   * <li> 'id'
710   *
711   * </ul> <p>
712   * @return <code>true</code> if the required attributes have been set, <code>false</code>
713   * otherwise.
714   */ public
715 boolean hasRequiredAttributes() {
716    return libsbmlJNI.CompartmentType_hasRequiredAttributes(swigCPtr, this);
717  }
718
719}