[GRASS-dev] Re: [GRASS GIS] #1230: <suppress_required/> in r.out.gdal

[GRASS GIS]

#1230: <suppress_required/> in r.out.gdal
--------------------------+-------------------------------------------------
  Reporter:  rsbivand     |       Owner:  grass-dev@…              
      Type:  defect       |      Status:  closed                   
  Priority:  major        |   Milestone:  7.0.0                    
 Component:  Raster       |     Version:  svn-trunk                
Resolution:  fixed        |    Keywords:                           
  Platform:  Unspecified  |         Cpu:  Unspecified              
--------------------------+-------------------------------------------------

Comment(by glynn):

 Replying to [comment:2 rsbivand]:

 > It may be permitted, but is much less obvious than
 >
 > <suppress_required>yes</suppress_required>
 > <suppress_required>no</suppress_required>
 >
 > which is arguably more portable.

 XML's support for the abbreviation of empty tags isn't an optional
 feature. If a parser doesn't handle it, it isn't an XML parser, it's a
 parser for an entirely different language.

 > I have to work within the XML library linked by the XML R contributed
 package, so if that barfs, I'm stuck. One problem seems to be that
 <description> has typically always been the first component, but where
 <suppress_required> appears, it is now first.

 I note that the --interface-description output doesn't conform to the
 stated DTD. But that was true before the suppress_required element was
 added (e.g. the DTD doesn't list "guisection" elements as being valid
 children for "flag" elements), so I'm guessing that this isn't actually
 the problem.

 I'm willing to fix both the DTD and the --interface-description output so
 that they match, although someone (probably Martin) will need to update
 the wx GUI. Based upon existing usage, I think that suppress_required may
 be better off as an attribute rather than a child element. OTOH, the split
 between which fields are attributes and which are child elements is rather
 arbitrary.

 > So some modules will optionally get an out-of-order component which,
 when present, means yes, and when absent means no? I guess I'm going to
 have to add code to loop through each flag entry checking the XML names,
 and set yes/no myself.

 You should be doing that anyhow. Most of the fields are marked as optional
 according to the DTD, so you can't assume that e.g. the first child is a
 description element.

 You can just ignore the suppress_required element if you aren't checking
 requirements. The wx GUI does check requirements, so that element had to
 be included in the interface description to prevent it from complaining
 (unnecessarily) about missing options.

 > Is the logic here that if I say "r.in.gdal -f", and if suppress_required
 is not set, one of the parameters may apply its required=YES value to
 terminate execution?

 Yes. Previously, if a module had a "special case" flag which invoked a
 different mode of execution, all of its options had to be listed as
 ->required=NO. The addition of the suppress_required fields allows
 options' ->required fields to be set based upon "normal" usage, rather
 than "worst-case" usage.

 > Can flags with and without suppress_required set be mixed?

 Yes. The only effect of that field is that if a flag with the
 suppress_required field is given, G_parser() suppresses the normal check
 that any options with ->required=YES are actually given.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/1230#comment:5>
GRASS GIS <http://grass.osgeo.org>