[Rpm-metadata] xml format - take 2

[Daniel Veillard]

On Tue, Sep 02, 2003 at 12:10:11AM -0400, seth vidal wrote:
> Hi all,

  Hi Seth,

> Changes:
>  using xml:base for the relative/explicit path layout
[...]
> Questions I have:
>  1. do I have to list the xmlns:xlink in the <doc> tag?

  Hum, I really didn't expected my prose or the XML specs to be 
that confusing, here is what I suggest:

1/ remove the doc, what's the point, and it's not closed...
2/ why exporting a namespace declaration for xlink if it is
   not used, why did you think it's needed ???
3/ the xml:base stuff still doesn't look good to me

<xml version="1.0" encoding="UTF-8">
<metadata>
  <package xml:base="ftp://local.server/local/path/"
           href="relative/path/package-1.1-1.2.i386.rpm>
  <origin xml:base="ftp://ftp.redhat.com/pub/linux/"
    href="relative/path/package-1.1-1.2.i386.rpm"
    sources="relative/path2/package-1.1-1.2.src.rpm"/>
  [...]
  <header-range start="123" end="9833" />
  <url>http://linux.duke.edu/mypackage</url>
  [...]
</metadata>

  And I would keep origin as optional. Similary package could have
a sources attribute indicating the source.

  Why:
    - because it's important to have explicitely a clear reference
      to the object of the metadata upfront.
    - reuse the common href="" usage for clarity
    - use xml:base to hint on the location of the mirroring and 
      minimize duplication of paths
    - do not mix metadata coming from the package spec itself <url>
      and metadata coming from the mirroring infrastructure
      (the href(s) and sources)

>  2. in the size tag I'm listing 3 things, rpm size, archivesize and
> installed size - does that really make much sense to anyone?
  
  What is needed ? The installed size is needed to check space ahead 
of trying to launch a transaction, and the rpm size might be needed
too to indicate transfer progress and check space on the local fs too,
the third one doesn't seem useful for our target space right now.

  I would keep origin, epoch, packager, vendor, group, buildhost,
size, url and header-range as optional, and possibly not even include
some of them in the spec. It's not the full set of metadata that
can be extracted from the package, but just the items needed.

<small_rant>
  My view point on trying to build standard especially around XML
is the following: provide something minimalist covering the needs for
80% of the use cases, keep the thing as small as possible, if needed
extension will be added by the 20% more and if they prove really useful
then standardize them in round 2. We need to focuse on keeping those
metadata as the minimal set needed to reach the goal, i.e. what's
stricly necessary as a common metadata set for installer and upgrade
tools. Anything outside might be neat, good ideas, etc... it will just
slow down design, testing and deployment in ways which are hard to 
estimate. It is very easy to get into piling "features" in round 1,
it introduces delays at all levels, we just need it good enough, then
deploy v1, then get some real test in the field, then come back at
v2 later if there is clear extensions done which would benefit from
"standardization". Believe me, I have been bitten hard in the past 
with "excessive features in v1" trend, let's not get there...
</small_rant>

  But in general Seth proposal looks very much to what we should aim at
in my opinion. Feedback from the engine implementors is really needed
at this point.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/