[SUMMARY] issues under contention in debian metadata

[apharris@burrito.onshore.com (Adam P. Harris)]

I'd like everyone to take a step back and relax. I'd like to thank
everyone for participating, and the rest of the debian-doc list for
onlooking.  Remember, we're all volunteers here for the fun of it.

These are the final issues under contention.  Some are resolved by
fiat in here for the next draft, some are just summarized for now.

Type element:
  This element shall stay, although it is considered experimental.
  Several suggested values will be provided, but maintainers can add
  new ones, at least during the experimental phase.  Of course display
  systems don't have to show it if they don't want to.

Rights element:
  This element shall stay.  A set of experiement "tokens" will be
  provided, such as GPL, NPL, LGPL, and "non-editable" (free but
  cannot be edited without restrictions).  It is felt that ability to
  have notation of the rights of the document is in line with the
  Debian Social Contract.

Document store:
  No central document store or API will be provided at this pass.
  However, a list of registered docreg files will be maintained by the
  system (i.e., this could be used by 'dhelp_parse -r').  Other lists
  are under consideration but probably won't be implemented in the
  first pass.

Docreg file placement:
  Still under debate.  As I say, I don't care where it goes; at this
  point I'm inclined to suggest that developers put in the
  HTML-accessible documentation area for their package.

Identifiers composition:
  Identifiers are crucial because it is likely that display
  implementations will copy data ("shadow") and changing identifier
  scheme would be painful.  Several alternate schemes are proposed:

  Marco's:           docreg file path + Identifier *or* URL
     pro - simple enough
     pro - FSSTD to FHS transition doesn't not require docreg change
     con - dislike the coupling between docreg file path and
           Identifier, suspect this will lead to orphaned objects in
           conjunction with FHS and problems with debugging, and
           widespread maintainer confusion.

  Marcus' straw man: Identifier is always absolute URL
     con - FSSTD to FHS transition requires docreg edits
     con - not really a serious proposal ?

  APH's URN: Identifier is URL, or a URN of the form
             'debian://package/<file relative to pkg doc area>'.
     pro - FSSTD to FHS transition doesn't not require docreg change
     pro - flexible URN2URL translation would allow use of central
           document systems
     pro - Identifier element is assured to be unique, at least within
           the pkg, since it contains the package name
     con - requires a URN2URL processor of some sort, which would have
           to gracefully cope with FSSTD->FHS
     con - wordy (could we have an implied syntax that wouldn't
           confuse people?)

Identifier uniqueness:
  Under debate.  I would propose the following: each metadata must
  refer to one and only one resource (URL or URN).  However, a URN or
  URN *may* have several metadata that refer to it.  Will this make
  display systems and data shadowing complex?  Basically, metadata
  identifiers would not have to be unique.

-- 
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>


--  
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org