[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: improving DevRef 6.2.2



Justin B Rye <jbr@edlug.org.uk> writes:

> Ben Finney wrote:
> > Okay. If there's no simple term to unambiguously mark what we're
> > describing, it's probably best to define what is meant in the
> > document, without any non-standard linguistic terminology.
> 
> One point I haven't mentioned is that the standard terminology for
> "noun phrase without an article" is "anarthrous NP", which is
> thoroughly opaque! I'll try "disarticulated" (but avoid implying
> it's official).

I'll only reiterate that, if there isn't a term widely used in
standard linguistic terminology, it may be clearer to avoid using any
apparently linguistic term in what is essentially a side discusion
with only the purpose of explanation and illustration.

> > Jut as a point of interest, and possibly to play devil's advocate:
> > *why* do we want the synopsis to not begin with an article ("a,
> > an, the" etc.)?
> [+ICY- good explanation +ICY-]

Thanks.

> >>>	The package "$NAME" provides {a,an,the,some} $SYNOPSIS. 
> >>
> >> (I'm still a bit unsure about including "some", though it does help
> >> accommodate plural NPs.)
> > 
> > The existing phrasing in +AKc-6.2.2 gives alternation for the copula:
> > "{is, are}", presumably to allow for a synopsis in the plural. So the
> > options so far presented still lead to awkwardness.
> 
> No, that's only intended to vary to allow for packages with
> apparently singular or plural names ("eg-utils are", "eg-tool is");
> it stays the same regardless of how the description is phrased
> ("...is/are a transition package for egtk").
> 
> And I prefer the idea that names of individual .deb files should
> always be treated as singular, whether they're derived from a
> singular noun phrase or a plural one.

Okay, it seems we agree here; I was confused over the examples, but
probably because I had already become muddied by the surounding
discussion.

> But the verb I was using was "provides"...
[+ICY-]

> 	"eg-utils provides a testing suite for libeg"
> 
> 	"eg-tool provides many libeg utilities (in one binary)"
> 
> Entirely natural either way.

Excellent, thanks for explaining again. I've got it now, and I agree
that makes the distinction much clearer.

> >> Oh, and single quotes, I missed that.
> > 
> > Perferably just as the Unicode characters themselves (+IBggGQ-) in the
> > document, rather than any fancy entity tricks to get them. (And
> > definitely not apostrophes!)
> 
> The best-pkging-practices.dbk source uses plain ASCII-39 apostrophes
> around 'Choices' (in 6.5.3), and that's the only example of quotes
> in the text!  Odd.  Shouldn't it be some sort of <q>...</q>? 

Quite probably.

Where were you proposing "oh, and single quotes"? In your suggested
rewritten section? I can't find that in your latest draft.

> > I think the de facto standard is the hyphen (as a stand-in for the
> > en dash +IBM-), but I believe the grammatical contortions are less
> > cumbersome if parentheses are used. Compare:
> > 
> >     "The package eg-tools is the simple exemplification system (utilities)."
> > 
> >     "The package eg-tools is the simple exemplification system +IBM- utilities."
> > 
> > Perhaps a quick straw poll of the existing package synopses is
> > appropriate, to see what the current majority practice is.
> 
> Tallying the 3600 packages installed on this Etch box, it's 224
> instances of ' - ' versus 237 instances of final ')'; both of those
> numbers include a lot of genuine instances of $ROLE, but brackets
> are also pretty common for things like "(based on libpoppler)".

(It seems I must be the typography geek to your linguistic geek: Those
are parentheses, not brackets :-)

Okay, so it seems there's no overwhelming majority of either the
pseudo-dash (with the hyphen-separated $ROLE) or the parentheses.

In which case, the parenthesis-delimited $ROLE, being clearer to read
to this biased reader, is the one I'll prefer. I see you've
standardised on that in your suggested section rewrite, so thumbs up
from me.

> Latest draft (where *foo*=<replaceable>foo</replaceable> and "foo"
> may end up as <quotation>foo</quotation>):

[+ICY-]

Looks good. With the exception of the above issue of where to use the
single quotes, I have no further changes to suggest.

-- 
 +AFw-       +IBw-The surest way to corrupt a youth is to instruct him to hold |
  `+AFw-       in higher esteem those who think alike than those who think |
_o__)                               differently.+IB0- +IBQ-Friedrich Nietzsche |
Ben Finney


Reply to: