001/* ----------------------------------------------------------------------------
002 * This file was automatically generated by SWIG (http://www.swig.org).
003 * Version 3.0.10
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 * <span class="pkg-marker pkg-color-comp"><a href="group__comp.html">comp</a></span>
013 Deletion of an object from a submodel.
014 <p>
015 * The {@link Deletion} class was introduced by the SBML Level&nbsp;3 <a href='../../../extensions-summary.html#comp'>Hierarchical Model Composition</a>
016 * (&ldquo;comp&rdquo;) package to allow elements of submodels to be removed
017 * before instantiation.
018<p>
019 * The {@link Deletion} object class is used to define a deletion operation
020 * to be applied when a submodel instantiates a model definition.
021 * Deletions may be useful in hierarchical model composition scenarios for
022 * various reasons.  For example, some components in a submodel may be
023 * redundant in the composed model, perhaps because the same features are
024 * implemented in a different way in the new model.
025<p>
026 * Deletions function as follows.  When the {@link Model} to which the {@link Submodel}
027 * object refers (via the 'modelRef' attribute) is read and processed for
028 * inclusion into the composed model, each {@link Deletion} object identifies an
029 * object to remove from that {@link Model} instance.  The resulting submodel
030 * instance consists of everything in the {@link Model} object instance minus the
031 * entities referenced by the list of {@link Deletion} objects.
032 <p>
033 * As might be expected, deletions can have wide-ranging implications,
034 * especially when the object deleted has substantial substructure, as in
035 * the case of reactions.  The following are rules regarding deletions and
036 * their effects.
037 <p>
038 * <ul>
039 * <li> An object that has been deleted is considered inaccessible.
040 * Any element that has been deleted (or replaced)
041 * may not be referenced by an {@link SBaseRef} object.
042 * <li> If the deleted object has child objects and other structures, the
043 * child objects and substructure are also considered to be deleted.
044 * <li> It is not an error to delete explicitly an object that is already
045 * deleted by implication (for example as a result of the second point
046 * above).  The resulting model is the same.
047 * <li> If the deleted object is from an SBML namespace that is not
048 * understood by the interpreter, the deletion must be ignored&mdash;the 
049 * object will not need to be deleted, as the interpreter could not
050 * understand the package.  If an interpreter cannot tell whether 
051 * a referenced object does not exist or if exists in an unparsed namespace
052 * it may produce a warning.
053 *
054 * </ul> <p>
055 * The {@link Deletion} object class is subclassed from {@link SBaseRef}, and reuses all the 
056 * machinery provided by {@link SBaseRef}.  In addition, it defines two optional 
057 * attributes, 'id' and 'name'.  The 'id' attribute can be used to give an
058 * identifier to a given deletion operation.  The identifier has no
059 * mathematical meaning, but it may be useful for creating submodels that
060 * can be manipulated more directly by other submodels.  (Indeed, it is
061 * legitimate for an enclosing model definition to delete a deletion!)
062 <p>
063 * The optional 'name' attribute is provided on {@link Deletion} for the
064 * same reason it is provided on other elements that have identifiers;
065 * viz., to provide for the possibility of giving a human-readable name to
066 * the object.  The name may be useful in situations when deletions are
067 * displayed to modelers.
068 */
069
070public class Deletion extends SBaseRef {
071   private long swigCPtr;
072
073   protected Deletion(long cPtr, boolean cMemoryOwn)
074   {
075     super(libsbmlJNI.Deletion_SWIGUpcast(cPtr), cMemoryOwn);
076     swigCPtr = cPtr;
077   }
078
079   protected static long getCPtr(Deletion obj)
080   {
081     return (obj == null) ? 0 : obj.swigCPtr;
082   }
083
084   protected static long getCPtrAndDisown (Deletion obj)
085   {
086     long ptr = 0;
087
088     if (obj != null)
089     {
090       ptr             = obj.swigCPtr;
091       obj.swigCMemOwn = false;
092     }
093
094     return ptr;
095   }
096
097  protected void finalize() {
098    delete();
099  }
100
101  public synchronized void delete() {
102    if (swigCPtr != 0) {
103      if (swigCMemOwn) {
104        swigCMemOwn = false;
105        libsbmlJNI.delete_Deletion(swigCPtr);
106      }
107      swigCPtr = 0;
108    }
109    super.delete();
110  }
111
112  
113/**
114   * Creates a new {@link Deletion} with the given level, version, and package version.
115   <p>
116   * @param level the SBML Level.
117   * @param version the Version within the SBML Level.
118   * @param pkgVersion the version of the package.
119   <p>
120   * <p>
121 * @note Attempting to add an object to an {@link SBMLDocument} having a different
122 * combination of SBML Level, Version and XML namespaces than the object
123 * itself will result in an error at the time a caller attempts to make the
124 * addition.  A parent object must have compatible Level, Version and XML
125 * namespaces.  (Strictly speaking, a parent may also have more XML
126 * namespaces than a child, but the reverse is not permitted.)  The
127 * restriction is necessary to ensure that an SBML model has a consistent
128 * overall structure.  This requires callers to manage their objects
129 * carefully, but the benefit is increased flexibility in how models can be
130 * created by permitting callers to create objects bottom-up if desired.  In
131 * situations where objects are not yet attached to parents (e.g.,
132 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
133 * libSBML determine such things as whether it is valid to assign a
134 * particular value to an attribute.  For packages, this means that the 
135 * parent object to which this package element is being added must have
136 * been created with the package namespace, or that the package namespace
137 * was added to it, even if that parent is not a package object itself.
138   */ public
139 Deletion(long level, long version, long pkgVersion) throws org.sbml.libsbml.SBMLConstructorException {
140    this(libsbmlJNI.new_Deletion__SWIG_0(level, version, pkgVersion), true);
141  }
142
143  
144/**
145   * Creates a new {@link Deletion} with the given level, version, and package version.
146   <p>
147   * @param level the SBML Level.
148   * @param version the Version within the SBML Level.
149   * @param pkgVersion the version of the package.
150   <p>
151   * <p>
152 * @note Attempting to add an object to an {@link SBMLDocument} having a different
153 * combination of SBML Level, Version and XML namespaces than the object
154 * itself will result in an error at the time a caller attempts to make the
155 * addition.  A parent object must have compatible Level, Version and XML
156 * namespaces.  (Strictly speaking, a parent may also have more XML
157 * namespaces than a child, but the reverse is not permitted.)  The
158 * restriction is necessary to ensure that an SBML model has a consistent
159 * overall structure.  This requires callers to manage their objects
160 * carefully, but the benefit is increased flexibility in how models can be
161 * created by permitting callers to create objects bottom-up if desired.  In
162 * situations where objects are not yet attached to parents (e.g.,
163 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
164 * libSBML determine such things as whether it is valid to assign a
165 * particular value to an attribute.  For packages, this means that the 
166 * parent object to which this package element is being added must have
167 * been created with the package namespace, or that the package namespace
168 * was added to it, even if that parent is not a package object itself.
169   */ public
170 Deletion(long level, long version) throws org.sbml.libsbml.SBMLConstructorException {
171    this(libsbmlJNI.new_Deletion__SWIG_1(level, version), true);
172  }
173
174  
175/**
176   * Creates a new {@link Deletion} with the given level, version, and package version.
177   <p>
178   * @param level the SBML Level.
179   * @param version the Version within the SBML Level.
180   * @param pkgVersion the version of the package.
181   <p>
182   * <p>
183 * @note Attempting to add an object to an {@link SBMLDocument} having a different
184 * combination of SBML Level, Version and XML namespaces than the object
185 * itself will result in an error at the time a caller attempts to make the
186 * addition.  A parent object must have compatible Level, Version and XML
187 * namespaces.  (Strictly speaking, a parent may also have more XML
188 * namespaces than a child, but the reverse is not permitted.)  The
189 * restriction is necessary to ensure that an SBML model has a consistent
190 * overall structure.  This requires callers to manage their objects
191 * carefully, but the benefit is increased flexibility in how models can be
192 * created by permitting callers to create objects bottom-up if desired.  In
193 * situations where objects are not yet attached to parents (e.g.,
194 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
195 * libSBML determine such things as whether it is valid to assign a
196 * particular value to an attribute.  For packages, this means that the 
197 * parent object to which this package element is being added must have
198 * been created with the package namespace, or that the package namespace
199 * was added to it, even if that parent is not a package object itself.
200   */ public
201 Deletion(long level) throws org.sbml.libsbml.SBMLConstructorException {
202    this(libsbmlJNI.new_Deletion__SWIG_2(level), true);
203  }
204
205  
206/**
207   * Creates a new {@link Deletion} with the given level, version, and package version.
208   <p>
209   * @param level the SBML Level.
210   * @param version the Version within the SBML Level.
211   * @param pkgVersion the version of the package.
212   <p>
213   * <p>
214 * @note Attempting to add an object to an {@link SBMLDocument} having a different
215 * combination of SBML Level, Version and XML namespaces than the object
216 * itself will result in an error at the time a caller attempts to make the
217 * addition.  A parent object must have compatible Level, Version and XML
218 * namespaces.  (Strictly speaking, a parent may also have more XML
219 * namespaces than a child, but the reverse is not permitted.)  The
220 * restriction is necessary to ensure that an SBML model has a consistent
221 * overall structure.  This requires callers to manage their objects
222 * carefully, but the benefit is increased flexibility in how models can be
223 * created by permitting callers to create objects bottom-up if desired.  In
224 * situations where objects are not yet attached to parents (e.g.,
225 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
226 * libSBML determine such things as whether it is valid to assign a
227 * particular value to an attribute.  For packages, this means that the 
228 * parent object to which this package element is being added must have
229 * been created with the package namespace, or that the package namespace
230 * was added to it, even if that parent is not a package object itself.
231   */ public
232 Deletion() throws org.sbml.libsbml.SBMLConstructorException {
233    this(libsbmlJNI.new_Deletion__SWIG_3(), true);
234  }
235
236  
237/**
238   * Creates a new {@link Deletion} with the given {@link CompPkgNamespaces} object.
239   <p>
240   * <p>
241 * The package namespaces object used in this constructor is derived from a
242 * {@link SBMLNamespaces} object, which encapsulates SBML Level/Version/namespaces
243 * information.  It is used to communicate the SBML Level, Version, and 
244 * package version and name information used in addition to SBML Level&nbsp;3 Core.  A
245 * common approach to using libSBML's {@link SBMLNamespaces} facilities is to create an
246 * package namespace object somewhere in a program once, then hand that object
247 * as needed to object constructors of that package that accept it as and
248 * argument, such as this one.
249   <p>
250   * @param compns the {@link CompPkgNamespaces} object.
251   <p>
252   * <p>
253 * @note Attempting to add an object to an {@link SBMLDocument} having a different
254 * combination of SBML Level, Version and XML namespaces than the object
255 * itself will result in an error at the time a caller attempts to make the
256 * addition.  A parent object must have compatible Level, Version and XML
257 * namespaces.  (Strictly speaking, a parent may also have more XML
258 * namespaces than a child, but the reverse is not permitted.)  The
259 * restriction is necessary to ensure that an SBML model has a consistent
260 * overall structure.  This requires callers to manage their objects
261 * carefully, but the benefit is increased flexibility in how models can be
262 * created by permitting callers to create objects bottom-up if desired.  In
263 * situations where objects are not yet attached to parents (e.g.,
264 * {@link SBMLDocument}), knowledge of the intented SBML Level and Version help
265 * libSBML determine such things as whether it is valid to assign a
266 * particular value to an attribute.  For packages, this means that the 
267 * parent object to which this package element is being added must have
268 * been created with the package namespace, or that the package namespace
269 * was added to it, even if that parent is not a package object itself.
270   */ public
271 Deletion(CompPkgNamespaces compns) throws org.sbml.libsbml.SBMLConstructorException {
272    this(libsbmlJNI.new_Deletion__SWIG_4(CompPkgNamespaces.getCPtr(compns), compns), true);
273  }
274
275  
276/**
277   * Copy constructor.
278   <p>
279   * @param source the {@link Deletion} instance to copy.
280   */ public
281 Deletion(Deletion source) throws org.sbml.libsbml.SBMLConstructorException {
282    this(libsbmlJNI.new_Deletion__SWIG_5(Deletion.getCPtr(source), source), true);
283  }
284
285  
286/**
287   * Creates and returns a deep copy of this {@link Deletion} object.
288   <p>
289   * @return a (deep) copy of this {@link Deletion} object.
290   */ public
291 SBase cloneObject() {
292    long cPtr = libsbmlJNI.Deletion_cloneObject(swigCPtr, this);
293    return (cPtr == 0) ? null : new Deletion(cPtr, true);
294  }
295
296  
297/**
298   * Sets the value of the 'id' attribute of this {@link Deletion}.
299   <p>
300   * <p>
301 * The string <code>sid</code> is copied.
302 <p>
303 * <p>
304 * The identifier given by an object's 'id' attribute value
305 * is used to identify the object within the SBML model definition.
306 * Other objects can refer to the component using this identifier.  The
307 * data type of 'id' is always <code>SId</code> or a type derived
308 * from that, such as <code>UnitSId</code>, depending on the object in 
309 * question.  All data types are defined as follows:
310 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
311 *   letter .= 'a'..'z','A'..'Z'
312 *   digit  .= '0'..'9'
313 *   idChar .= letter | digit | '_'
314 *   SId    .= ( letter | '_' ) idChar*
315 * </pre>
316 <p>
317 * The characters <code>(</code> and <code>)</code> are used for grouping, the
318 * character <code>*</code> 'zero or more times', and the character
319 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
320 * determined by an exact character sequence match; i.e., comparisons must be
321 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
322 * <code>SIdRef</code>, and derived types.
323 <p>
324 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
325 * moved to {@link SBase} directly, instead of being defined individually for many
326 * (but not all) objects.  Libsbml has for a long time provided functions
327 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
328 * would fail or otherwise return empty strings if executed on any object 
329 * for which those attributes were not defined.  Now that all {@link SBase} objects 
330 * define those attributes, those functions now succeed for any object with 
331 * the appropriate level and version.
332 <p>
333 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
334 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
335 * functions (though not the setId() or unsetId() functions) would instead 
336 * reference the value of the 'variable' attribute (for the rules and event 
337 * assignments) or the 'symbol' attribute (for initial assignments).  
338 * The {@link AlgebraicRule} fell into this category as well, though because it 
339 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
340 * always return an empty string, and isSetId() would always return <code>false.</code>
341 * For this reason, four new functions are now provided 
342 * (getIdAttribute(), setIdAttribute(String), 
343 * isSetIdAttribute(), and unsetIdAttribute()) that will always
344 * act on the actual 'id' attribute, regardless of the object's type.  The
345 * new functions should be used instead of the old ones unless the old behavior
346 * is somehow necessary.
347 <p>
348 * Regardless of the level and version of the SBML, these functions allow
349 * client applications to use more generalized code in some situations 
350 * (for instance, when manipulating objects that are all known to have 
351 * identifiers).  If the object in question does not posess an 'id' attribute 
352 * according to the SBML specification for the Level and Version in use,
353 * libSBML will not allow the identifier to be set, nor will it read or 
354 * write 'id' attributes for those objects.
355 <p>
356 * @param sid the string to use as the identifier of this object.
357 <p>
358 * <p>
359 * @return integer value indicating success/failure of the
360 * function.   The possible values
361 * returned by this function are:
362 * <ul>
363 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
364 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
365 * <li> {@link libsbmlConstants#LIBSBML_UNEXPECTED_ATTRIBUTE LIBSBML_UNEXPECTED_ATTRIBUTE}
366 *
367 * </ul> <p>
368 * @see #getIdAttribute()
369 * @see #setIdAttribute(String sid)
370 * @see #isSetIdAttribute()
371 * @see #unsetIdAttribute()
372   */ public
373 int setId(String sid) {
374    return libsbmlJNI.Deletion_setId(swigCPtr, this, sid);
375  }
376
377  
378/**
379   * Returns the value of the 'id' attribute of this {@link Deletion}.
380   <p>
381   * @note Because of the inconsistent behavior of this function with 
382   * respect to assignments and rules, it is now recommended to
383   * use the getIdAttribute() function instead.
384   <p>
385   * <p>
386 * The identifier given by an object's 'id' attribute value
387 * is used to identify the object within the SBML model definition.
388 * Other objects can refer to the component using this identifier.  The
389 * data type of 'id' is always <code>SId</code> or a type derived
390 * from that, such as <code>UnitSId</code>, depending on the object in 
391 * question.  All data types are defined as follows:
392 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
393 *   letter .= 'a'..'z','A'..'Z'
394 *   digit  .= '0'..'9'
395 *   idChar .= letter | digit | '_'
396 *   SId    .= ( letter | '_' ) idChar*
397 * </pre>
398 <p>
399 * The characters <code>(</code> and <code>)</code> are used for grouping, the
400 * character <code>*</code> 'zero or more times', and the character
401 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
402 * determined by an exact character sequence match; i.e., comparisons must be
403 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
404 * <code>SIdRef</code>, and derived types.
405 <p>
406 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
407 * moved to {@link SBase} directly, instead of being defined individually for many
408 * (but not all) objects.  Libsbml has for a long time provided functions
409 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
410 * would fail or otherwise return empty strings if executed on any object 
411 * for which those attributes were not defined.  Now that all {@link SBase} objects 
412 * define those attributes, those functions now succeed for any object with 
413 * the appropriate level and version.
414 <p>
415 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
416 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
417 * functions (though not the setId() or unsetId() functions) would instead 
418 * reference the value of the 'variable' attribute (for the rules and event 
419 * assignments) or the 'symbol' attribute (for initial assignments).  
420 * The {@link AlgebraicRule} fell into this category as well, though because it 
421 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
422 * always return an empty string, and isSetId() would always return <code>false.</code>
423 * For this reason, four new functions are now provided 
424 * (getIdAttribute(), setIdAttribute(String), 
425 * isSetIdAttribute(), and unsetIdAttribute()) that will always
426 * act on the actual 'id' attribute, regardless of the object's type.  The
427 * new functions should be used instead of the old ones unless the old behavior
428 * is somehow necessary.
429 <p>
430 * Regardless of the level and version of the SBML, these functions allow
431 * client applications to use more generalized code in some situations 
432 * (for instance, when manipulating objects that are all known to have 
433 * identifiers).  If the object in question does not posess an 'id' attribute 
434 * according to the SBML specification for the Level and Version in use,
435 * libSBML will not allow the identifier to be set, nor will it read or 
436 * write 'id' attributes for those objects.
437   <p>
438   * @return the id of this {@link Deletion}.
439   <p>
440   * @see #getIdAttribute()
441   * @see #setIdAttribute(String sid)
442   * @see #isSetIdAttribute()
443   * @see #unsetIdAttribute()
444   */ public
445 String getId() {
446    return libsbmlJNI.Deletion_getId(swigCPtr, this);
447  }
448
449  
450/**
451   * Predicate returning <code>true</code> or <code>false</code> depending on whether this
452   * object's 'id' attribute has been set.
453   <p>
454   * <p>
455 * @note Because of the inconsistent behavior of this function with 
456 * respect to assignments and rules, it is now recommended to
457 * use the isSetIdAttribute() function instead.
458 <p>
459 * <p>
460 * The identifier given by an object's 'id' attribute value
461 * is used to identify the object within the SBML model definition.
462 * Other objects can refer to the component using this identifier.  The
463 * data type of 'id' is always <code>SId</code> or a type derived
464 * from that, such as <code>UnitSId</code>, depending on the object in 
465 * question.  All data types are defined as follows:
466 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
467 *   letter .= 'a'..'z','A'..'Z'
468 *   digit  .= '0'..'9'
469 *   idChar .= letter | digit | '_'
470 *   SId    .= ( letter | '_' ) idChar*
471 * </pre>
472 <p>
473 * The characters <code>(</code> and <code>)</code> are used for grouping, the
474 * character <code>*</code> 'zero or more times', and the character
475 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
476 * determined by an exact character sequence match; i.e., comparisons must be
477 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
478 * <code>SIdRef</code>, and derived types.
479 <p>
480 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
481 * moved to {@link SBase} directly, instead of being defined individually for many
482 * (but not all) objects.  Libsbml has for a long time provided functions
483 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
484 * would fail or otherwise return empty strings if executed on any object 
485 * for which those attributes were not defined.  Now that all {@link SBase} objects 
486 * define those attributes, those functions now succeed for any object with 
487 * the appropriate level and version.
488 <p>
489 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
490 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
491 * functions (though not the setId() or unsetId() functions) would instead 
492 * reference the value of the 'variable' attribute (for the rules and event 
493 * assignments) or the 'symbol' attribute (for initial assignments).  
494 * The {@link AlgebraicRule} fell into this category as well, though because it 
495 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
496 * always return an empty string, and isSetId() would always return <code>false.</code>
497 * For this reason, four new functions are now provided 
498 * (getIdAttribute(), setIdAttribute(String), 
499 * isSetIdAttribute(), and unsetIdAttribute()) that will always
500 * act on the actual 'id' attribute, regardless of the object's type.  The
501 * new functions should be used instead of the old ones unless the old behavior
502 * is somehow necessary.
503 <p>
504 * Regardless of the level and version of the SBML, these functions allow
505 * client applications to use more generalized code in some situations 
506 * (for instance, when manipulating objects that are all known to have 
507 * identifiers).  If the object in question does not posess an 'id' attribute 
508 * according to the SBML specification for the Level and Version in use,
509 * libSBML will not allow the identifier to be set, nor will it read or 
510 * write 'id' attributes for those objects.
511 <p>
512 * @return <code>true</code> if the 'id' attribute of this SBML object is
513 * set, <code>false</code> otherwise.
514 <p>
515 * @see #getIdAttribute()
516 * @see #setIdAttribute(String sid)
517 * @see #unsetIdAttribute()
518 * @see #isSetIdAttribute()
519   */ public
520 boolean isSetId() {
521    return libsbmlJNI.Deletion_isSetId(swigCPtr, this);
522  }
523
524  
525/**
526   * Unsets the value of the 'id' attribute of this {@link Deletion}.
527   <p>
528   * <p>
529 * <p>
530 * The identifier given by an object's 'id' attribute value
531 * is used to identify the object within the SBML model definition.
532 * Other objects can refer to the component using this identifier.  The
533 * data type of 'id' is always <code>SId</code> or a type derived
534 * from that, such as <code>UnitSId</code>, depending on the object in 
535 * question.  All data types are defined as follows:
536 * <pre style='margin-left: 2em; border: none; font-weight: bold; color: black'>
537 *   letter .= 'a'..'z','A'..'Z'
538 *   digit  .= '0'..'9'
539 *   idChar .= letter | digit | '_'
540 *   SId    .= ( letter | '_' ) idChar*
541 * </pre>
542 <p>
543 * The characters <code>(</code> and <code>)</code> are used for grouping, the
544 * character <code>*</code> 'zero or more times', and the character
545 * <code>|</code> indicates logical 'or'.  The equality of SBML identifiers is
546 * determined by an exact character sequence match; i.e., comparisons must be
547 * performed in a case-sensitive manner.  This applies to all uses of <code>SId</code>, 
548 * <code>SIdRef</code>, and derived types.
549 <p>
550 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
551 * moved to {@link SBase} directly, instead of being defined individually for many
552 * (but not all) objects.  Libsbml has for a long time provided functions
553 * defined on {@link SBase} itself to get, set, check, and unset those attributes, which 
554 * would fail or otherwise return empty strings if executed on any object 
555 * for which those attributes were not defined.  Now that all {@link SBase} objects 
556 * define those attributes, those functions now succeed for any object with 
557 * the appropriate level and version.
558 <p>
559 * The exception to this rule is that for {@link InitialAssignment}, {@link EventAssignment}, 
560 * {@link AssignmentRule}, and {@link RateRule} objects, the getId() function and the isSetId() 
561 * functions (though not the setId() or unsetId() functions) would instead 
562 * reference the value of the 'variable' attribute (for the rules and event 
563 * assignments) or the 'symbol' attribute (for initial assignments).  
564 * The {@link AlgebraicRule} fell into this category as well, though because it 
565 * contained neither a 'variable' nor a 'symbol' attribute, getId() would 
566 * always return an empty string, and isSetId() would always return <code>false.</code>
567 * For this reason, four new functions are now provided 
568 * (getIdAttribute(), setIdAttribute(String), 
569 * isSetIdAttribute(), and unsetIdAttribute()) that will always
570 * act on the actual 'id' attribute, regardless of the object's type.  The
571 * new functions should be used instead of the old ones unless the old behavior
572 * is somehow necessary.
573 <p>
574 * Regardless of the level and version of the SBML, these functions allow
575 * client applications to use more generalized code in some situations 
576 * (for instance, when manipulating objects that are all known to have 
577 * identifiers).  If the object in question does not posess an 'id' attribute 
578 * according to the SBML specification for the Level and Version in use,
579 * libSBML will not allow the identifier to be set, nor will it read or 
580 * write 'id' attributes for those objects.
581 <p>
582 * <p>
583 * @return integer value indicating success/failure of the
584 * function.   The possible values
585 * returned by this function are:
586 * <ul>
587 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
588 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
589 *
590 * </ul> <p>
591 * @see #getIdAttribute()
592 * @see #setIdAttribute(String sid)
593 * @see #isSetIdAttribute()
594 * @see #unsetIdAttribute()
595   */ public
596 int unsetId() {
597    return libsbmlJNI.Deletion_unsetId(swigCPtr, this);
598  }
599
600  
601/**
602   * Sets the value of the 'name' attribute of this {@link Deletion}.
603   <p>
604   * <p>
605 * The string in <code>name</code> is copied.
606 <p>
607 * @param name the new name for the SBML object.
608 <p>
609 * <p>
610 * @return integer value indicating success/failure of the
611 * function.   The possible values
612 * returned by this function are:
613 * <ul>
614 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
615 * <li> {@link libsbmlConstants#LIBSBML_INVALID_ATTRIBUTE_VALUE LIBSBML_INVALID_ATTRIBUTE_VALUE}
616 *
617 * </ul>
618   */ public
619 int setName(String name) {
620    return libsbmlJNI.Deletion_setName(swigCPtr, this, name);
621  }
622
623  
624/**
625   * Returns the value of the 'name' attribute of this {@link Deletion} object.
626   <p>
627   * <p>
628 * <p>
629 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
630 * moved to {@link SBase} directly, instead of being defined individually for many
631 * (but not all) objects.  Libsbml has for a long time provided functions
632 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
633 * would fail or otherwise return empty strings if executed on any object 
634 * for which those attributes were not defined.  Now that all {@link SBase} objects 
635 * define those attributes, those functions now succeed for any object with 
636 * the appropriate level and version.
637 <p>
638 * The 'name' attribute is
639 * optional and is not intended to be used for cross-referencing purposes
640 * within a model.  Its purpose instead is to provide a human-readable
641 * label for the component.  The data type of 'name' is the type
642 * <code>string</code> defined in XML Schema.  SBML imposes no
643 * restrictions as to the content of 'name' attributes beyond those
644 * restrictions defined by the <code>string</code> type in XML Schema.
645 <p>
646 * The recommended practice for handling 'name' is as follows.  If a
647 * software tool has the capability for displaying the content of 'name'
648 * attributes, it should display this content to the user as a
649 * component's label instead of the component's 'id'.  If the user
650 * interface does not have this capability (e.g., because it cannot
651 * display or use special characters in symbol names), or if the 'name'
652 * attribute is missing on a given component, then the user interface
653 * should display the value of the 'id' attribute instead.  (Script
654 * language interpreters are especially likely to display 'id' instead of
655 * 'name'.)
656 <p>
657 * As a consequence of the above, authors of systems that automatically
658 * generate the values of 'id' attributes should be aware some systems
659 * may display the 'id''s to the user.  Authors therefore may wish to
660 * take some care to have their software create 'id' values that are: (a)
661 * reasonably easy for humans to type and read; and (b) likely to be
662 * meaningful, for example by making the 'id' attribute be an abbreviated
663 * form of the name attribute value.
664 <p>
665 * An additional point worth mentioning is although there are
666 * restrictions on the uniqueness of 'id' values, there are no
667 * restrictions on the uniqueness of 'name' values in a model.  This
668 * allows software applications leeway in assigning component identifiers.
669 <p>
670 * Regardless of the level and version of the SBML, these functions allow
671 * client applications to use more generalized code in some situations 
672 * (for instance, when manipulating objects that are all known to have 
673 * names).  If the object in question does not posess a 'name' attribute 
674 * according to the SBML specification for the Level and Version in use,
675 * libSBML will not allow the name to be set, nor will it read or 
676 * write 'name' attributes for those objects.
677 <p>
678 * @return the name of this SBML object, or the empty string if not set or unsettable.
679 <p>
680 * @see #getIdAttribute()
681 * @see #isSetName()
682 * @see #setName(String sid)
683 * @see #unsetName()
684   */ public
685 String getName() {
686    return libsbmlJNI.Deletion_getName(swigCPtr, this);
687  }
688
689  
690/**
691   * Predicate returning <code>true</code> or <code>false</code> depending on whether this
692   * object's 'name' attribute has been set.
693   <p>
694   * <p>
695 * <p>
696 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
697 * moved to {@link SBase} directly, instead of being defined individually for many
698 * (but not all) objects.  Libsbml has for a long time provided functions
699 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
700 * would fail or otherwise return empty strings if executed on any object 
701 * for which those attributes were not defined.  Now that all {@link SBase} objects 
702 * define those attributes, those functions now succeed for any object with 
703 * the appropriate level and version.
704 <p>
705 * The 'name' attribute is
706 * optional and is not intended to be used for cross-referencing purposes
707 * within a model.  Its purpose instead is to provide a human-readable
708 * label for the component.  The data type of 'name' is the type
709 * <code>string</code> defined in XML Schema.  SBML imposes no
710 * restrictions as to the content of 'name' attributes beyond those
711 * restrictions defined by the <code>string</code> type in XML Schema.
712 <p>
713 * The recommended practice for handling 'name' is as follows.  If a
714 * software tool has the capability for displaying the content of 'name'
715 * attributes, it should display this content to the user as a
716 * component's label instead of the component's 'id'.  If the user
717 * interface does not have this capability (e.g., because it cannot
718 * display or use special characters in symbol names), or if the 'name'
719 * attribute is missing on a given component, then the user interface
720 * should display the value of the 'id' attribute instead.  (Script
721 * language interpreters are especially likely to display 'id' instead of
722 * 'name'.)
723 <p>
724 * As a consequence of the above, authors of systems that automatically
725 * generate the values of 'id' attributes should be aware some systems
726 * may display the 'id''s to the user.  Authors therefore may wish to
727 * take some care to have their software create 'id' values that are: (a)
728 * reasonably easy for humans to type and read; and (b) likely to be
729 * meaningful, for example by making the 'id' attribute be an abbreviated
730 * form of the name attribute value.
731 <p>
732 * An additional point worth mentioning is although there are
733 * restrictions on the uniqueness of 'id' values, there are no
734 * restrictions on the uniqueness of 'name' values in a model.  This
735 * allows software applications leeway in assigning component identifiers.
736 <p>
737 * Regardless of the level and version of the SBML, these functions allow
738 * client applications to use more generalized code in some situations 
739 * (for instance, when manipulating objects that are all known to have 
740 * names).  If the object in question does not posess a 'name' attribute 
741 * according to the SBML specification for the Level and Version in use,
742 * libSBML will not allow the name to be set, nor will it read or 
743 * write 'name' attributes for those objects.
744 <p>
745 * @return <code>true</code> if the 'name' attribute of this SBML object is
746 * set, <code>false</code> otherwise.
747 <p>
748 * @see #getName()
749 * @see #setName(String sid)
750 * @see #unsetName()
751   */ public
752 boolean isSetName() {
753    return libsbmlJNI.Deletion_isSetName(swigCPtr, this);
754  }
755
756  
757/**
758   * Unsets the value of the 'name' attribute of this {@link Deletion}.
759   <p>
760   * <p>
761 * <p>
762 * In SBML Level&nbsp;3 Version&nbsp;2, the 'id' and 'name' attributes were
763 * moved to {@link SBase} directly, instead of being defined individually for many
764 * (but not all) objects.  Libsbml has for a long time provided functions
765 * defined on {@link SBase} itself to get, set, and unset those attributes, which 
766 * would fail or otherwise return empty strings if executed on any object 
767 * for which those attributes were not defined.  Now that all {@link SBase} objects 
768 * define those attributes, those functions now succeed for any object with 
769 * the appropriate level and version.
770 <p>
771 * The 'name' attribute is
772 * optional and is not intended to be used for cross-referencing purposes
773 * within a model.  Its purpose instead is to provide a human-readable
774 * label for the component.  The data type of 'name' is the type
775 * <code>string</code> defined in XML Schema.  SBML imposes no
776 * restrictions as to the content of 'name' attributes beyond those
777 * restrictions defined by the <code>string</code> type in XML Schema.
778 <p>
779 * The recommended practice for handling 'name' is as follows.  If a
780 * software tool has the capability for displaying the content of 'name'
781 * attributes, it should display this content to the user as a
782 * component's label instead of the component's 'id'.  If the user
783 * interface does not have this capability (e.g., because it cannot
784 * display or use special characters in symbol names), or if the 'name'
785 * attribute is missing on a given component, then the user interface
786 * should display the value of the 'id' attribute instead.  (Script
787 * language interpreters are especially likely to display 'id' instead of
788 * 'name'.)
789 <p>
790 * As a consequence of the above, authors of systems that automatically
791 * generate the values of 'id' attributes should be aware some systems
792 * may display the 'id''s to the user.  Authors therefore may wish to
793 * take some care to have their software create 'id' values that are: (a)
794 * reasonably easy for humans to type and read; and (b) likely to be
795 * meaningful, for example by making the 'id' attribute be an abbreviated
796 * form of the name attribute value.
797 <p>
798 * An additional point worth mentioning is although there are
799 * restrictions on the uniqueness of 'id' values, there are no
800 * restrictions on the uniqueness of 'name' values in a model.  This
801 * allows software applications leeway in assigning component identifiers.
802 <p>
803 * Regardless of the level and version of the SBML, these functions allow
804 * client applications to use more generalized code in some situations 
805 * (for instance, when manipulating objects that are all known to have 
806 * names).  If the object in question does not posess a 'name' attribute 
807 * according to the SBML specification for the Level and Version in use,
808 * libSBML will not allow the name to be set, nor will it read or 
809 * write 'name' attributes for those objects.
810 <p>
811 * <p>
812 * @return integer value indicating success/failure of the
813 * function.   The possible values
814 * returned by this function are:
815 * <ul>
816 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
817 * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
818 *
819 * </ul> <p>
820 * @see #getName()
821 * @see #setName(String sid)
822 * @see #isSetName()
823   */ public
824 int unsetName() {
825    return libsbmlJNI.Deletion_unsetName(swigCPtr, this);
826  }
827
828  
829/**
830   * Returns the XML element name of this SBML object.
831   <p>
832   * @return the name of this element, as a text string.
833   */ public
834 String getElementName() {
835    return libsbmlJNI.Deletion_getElementName(swigCPtr, this);
836  }
837
838  
839/**
840   * Returns the libSBML type code of this object instance.
841   <p>
842   * <p>
843 * LibSBML attaches an identifying code to every kind of SBML object.  These
844 * are integer constants known as <em>SBML type codes</em>.  The names of all
845 * the codes begin with the characters <code>SBML_</code>.
846 * In the Java language interface for libSBML, the
847 * type codes are defined as static integer constants in the interface class
848 * {@link libsbmlConstants}.    Note that different Level&nbsp;3
849 * package plug-ins may use overlapping type codes; to identify the package
850 * to which a given object belongs, call the <code>getPackageName()</code>
851 * method on the object.
852   <p>
853   * @return the SBML type code for this object:
854   * {@link libsbmlConstants#SBML_COMP_DELETION SBML_COMP_DELETION}.
855   <p>
856   * <p>
857 * @warning <span class='warning'>The specific integer values of the possible
858 * type codes may be reused by different libSBML plug-ins for SBML Level&nbsp;3.
859 * packages,  To fully identify the correct code, <strong>it is necessary to
860 * invoke both getTypeCode() and getPackageName()</strong>.</span>
861   <p>
862   * @see #getElementName()
863   * @see #getPackageName()
864   */ public
865 int getTypeCode() {
866    return libsbmlJNI.Deletion_getTypeCode(swigCPtr, this);
867  }
868
869  
870/**
871   * Finds and stores the referenced object.  It finds its {@link Submodel} parent,
872   * gets its instantiated {@link Model} object, calls
873   * 'getReferencedElementFrom()' using that model, and stores the result.
874   <p>
875   * <p>
876 * @return integer value indicating success/failure of the
877 * function.   The possible values
878 * returned by this function are:
879   * <ul>
880   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_SUCCESS LIBSBML_OPERATION_SUCCESS}
881   * <li> {@link libsbmlConstants#LIBSBML_OPERATION_FAILED LIBSBML_OPERATION_FAILED}
882   * </ul>
883   */ public
884 int saveReferencedElement() {
885    return libsbmlJNI.Deletion_saveReferencedElement(swigCPtr, this);
886  }
887
888}