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

GRASS GIS trac at osgeo.org
Tue Dec 7 04:00:35 EST 2010


#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 rsbivand):

 Replying to [comment:5 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.
 >

 Glynn,

 Thanks, I understand now. In the revision reported above, I look at the
 child names, and set a value to TRUE for each R flag object if
 "suppress_required" is among the names, otherwise FALSE.

 > > 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.

 No, they just always had been before, my mistake.

 >
 > 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.
 >

 I am checking requirements.

 > > 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.


 Thanks. That seems clear enough - note that I closed this ticket once I'd
 realised that the problem was on my side.

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



More information about the grass-dev mailing list