Re: improving DevRef 6.2.2
Ben Finney wrote:
>> That second paragraph is where the trouble starts.
>>
>> First, valid package synopses aren't clauses. Clauses have verbs.
>
> Is there a better, specific, term for what "red-nosed reindeer" is in
> the phrase "Rudolph the red-nosed reindeer"?
"THE red-nosed reindeer" would be an appositive noun phrase; in the
conventional X-bar phrase structure terminology I learned at uni,
the thing you prefix a determiner (Det) to in order to produce a
noun phrase (NP) is usually labelled an Nʺ (N-double-bar). Pretty
esoteric, and that's before I start trying to type overbars!
>> Second, ["appositive clause" isn't defined in WordNet and means
>> something different in grammar dictionaries]
>
> That's sufficient reason, I think, to stop using the term in the
> context of the package synopsis.
>
>> […] package synopses as they occur in package-lists might be
>> interpreted as being appositive noun phrases... if it wasn't for the
>> fact that they drop their initial definite/indefinite article (which
>> is a constituent of the noun phrase).
>
> Do linguists have a standard term for such a thing then?
Once you get below the level of NPs and VPs the labelling isn't
well standardised. There are alternative schools of thought that
would give the same constituent a different label.
And whatever we call the constituent consisting of an NP minus Det,
that syntactic unit doesn't even precisely match what we're trying
to prescribe: Det includes other things besides articles, some of
which we prune and others of which we don't. Possessives, for
instance. The package synopsis for xlife is "John Conway's Game of
Life, for X11", where the first two words fill the determiner slot,
making the package description a full NP.
The nearest thing to a cover-term is "nominal" (anything noun-y,
including N, Nʹ, Nʺ or NP); but vagueness doesn't get us anywhere,
because it's only the full NP that's ever in the syntactic
relationship of apposition with anything.
What we _could_ say is that they're appositive noun phrases EXCEPT
THAT they drop leading articles.
>> If you're finding this annoyingly technical, well, that's the bigger
>> problem. Even if everything else was correct, it wouldn't be "a good
>> idea" to explain things this way. After all, this synopsis format
>> isn't recommended on the basis of its superior syntax, it's just a
>> matter of standardising on common good practice.
>
> Yes, this has been my main motivation in asking people to follow Dev
> Ref §6.2.2. Nothing to do with superior language, but rather for
> standardising the format to facilitate more reliable and flexible use
> of synopses (as is the goal with most standardisation effort).
And this is why I didn't want to go blundering into debian-mentors
shouting "it's not an appositive clause!" - the advice I see being
given is good, it's only the rationale that's problematic.
>> Software developers have no reason to know or care about the
>> appropriate labels for English phrase structures; basing the rule on
>> their understanding of a particular grammatical analysis is a _bad_
>> idea.
>
> Software developers do, though, have a tendency to want to know the
> technical justification for a particular rule; this extends often to
> rules of language. I think there's value in at least referring the
> reader to a linguistic term that they can pursue to find out more.
The syntax isn't the reason for the rule (if it was, we'd have
standardised on something that was a nice clear constituent!); it's
only relevant if you need to come up with a syntactically watertight
_description_ of the rule.
On the other hand it might help if the DevRef section went into it
as far as the difference between Noun Phrases and Verb Phrases,
since VP ("does something useful") is the other kind of phrase
people most often try to use.
>> It's also worth noticing that DevRef's mention of apposition has
>> nothing to do with the rule against articles (witness the fact that
>> "Rudolph the red-nosed reindeer" does have a definite article). The
>> trimming of "a/the" isn't grammatically motivated; it's an extra
>> rule designed to reduce redundancy.
>
> I se it as a reflexive explanation of the form from the desire that
> the synopsis to fit the hypothetical §6.2.2 template "<packagename> is
> <article> <synopsis>". I still find that desirable, and would like to
> see it grammatically explained, even briefly.
The template is good, but in that context it _isn't_ in apposition,
it's an ordinary predicate NP (until you trim the article).
>> ---------------------------------------------------------------------
>> | Policy says the synopsis line (the short description) must be
>> | concise, not repeating the package name, but also informative.
>> |
>> | The synopsis functions as a phrase describing the package, not as
>> | a complete sentence, so sentential punctuation is inappropriate:
>> | it does not need extra capital letters or a final period (full
>> | stop). It should also omit any initial indefinite or definite
>> | article ("a(n)/the"). Thus for instance:
>
> I'd find this easier to parse if it just listed the three articles as
> "a, an, the".
Thanks, that's the kind of detail I stop seeing after a couple of
rewrites.
>> | libeg0 - exemplification support library
>
> In a section discussing synopses, this "for instance" should show the
> synopsis. Instead it confusingly shows the package name, when the
> reader has already ben told not to repeat the package name.
>
> Perhaps this would be better shown as two control fields:
>
> Package: libeg0
> Description: exemplification support library
>
> Alternatively, the explanatory text could state what example package
> name is being used, while showing only synopsis values for
> illustration.
That two-field approach would help make the good examples visually
distinct from the template lines.
>> | A good heuristic is that it should be possible to substitute the
>> | package name and synopsis into this formula:
>> |
>> | The package "$NAME" provides [a(n)|the|some] $SYNOPSIS.
>
> Again, this would be easier (for this sysadmin) to read if given as:
>
> 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.)
By the way, when I say "$FOO", it's possible I should just be using
the "<replaceable>foo</replaceable>" docbook markup in the current
DevRef. Oh, and single quotes, I missed that.
>> | Sets of related packages may use an alternative scheme that divides
>> | the synopsis into two parts, the first a description of the whole
>> | suite and the second a summary of the package's role within it:
>> |
>> | eg-tools - simple exemplification system (utilities)
>
> This might be clearer if two illustrations were given for comparison:
>
> Package: eg-tools
> Description: simple exemplification system (utilities)
> …
>
> Package: eg-doc
> Description: simple exemplification system (documentation)
> …
Absolutely.
Oh, by the way - parentheses or dashes? I tend to like "($ROLE)",
but I think d-l-e has recommended "- $ROLE" in the past, and we
probably don't want to imply we're deprecating either.
>> | These suite-and-role synopses need a modified formula:
>> |
>> | The package "$NAME" provides [a...] $ROLE for [a...] $SUITE
>
> Unclear. Perhaps "These synopses follow an extended formula to the
> simple one above. The synopsis of the package $NAME expressed as
> '$SUITE ($ROLE)' can be described in a sentence such as 'The package
> $NAME provides $ROLE for {a,an,the,some} $SUITE.'."
Okay, but I'd prefer something like:
These synopses follow an extended formula based on the simple one
above. Where a package $NAME has a synopsis $SUITE ($ROLE), the
elements should be phrased so that they fit into the formula
The package $NAME provides $ROLE for {a,an,the,some} $SUITE.
Roles can occasionally want an article, as in
Package: egd
Description: simple exemplification system (daemon)
where it provides *a* (or perhaps *the*) $ROLE for the $SUITE.
In fact, do suites ever want an indefinite article? They're always
at least "the particular simple exemplification system that these
docs are for"; I should look through the listings for examples.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: