Re: [Scrollkeeper-devel] omf question

[David M. <da...@lu...>]

On Fri, Mar 16, 2001 at 11:19:08AM -0500, Paul Jones wrote:
> let me take a crack at answering your questions and other omf folks please
> correct me.
> 
> On Thu, 15 Mar 2001, David Merrill wrote:
> 
> +    # You don't have version information in your example.
> +    # I dont' know if ours is right yet, either. This is a pre-alpha
> +    # (non) release.
> +    <versionGroup created="20010315">
> +      <version created="20010315">
> +        <id created="20010315">
> officially you would not be required to enter a version number as it is
> optional information see http://www.ibiblio.org/osrt/omf/omf_elements

Even if it is optional according to omf, I don't think we should
consider it optional for our purposes. It is very valuable information
and scrollkeeper will definitely need it.

> +          # I suspect this is wrong. Too much info. But it could exist
> +	  # in the original docbook, too. Haven't checked that yet.
> +	  # This is why I want to get started doing omf early. There
> +	  # will be wrinkles to work out. We may have to update all
> +	  # our documents' source.
> +          0.6c15 Feb 2001konst
> +        </id>
> +        <date created="20010315">
> +          20010215
> +        </date>
> +      </version>
> +    </versionGroup>
> +
> you are right we don't support a sub-label of category. how would you
> define that?

I have *no* idea. You can see that sk has used a pipe char to separate
them. This seems workable but it would be better to do:

<category>
  <major>System<major>
  <minor>Other</minor>
</category>

or something similar.

> +    # Note that we do not have categories. We need your advice.
> +    # Have you established a system of categorization? I see the
> +    # <subject><category>System|Other</category></subject>, but I am
> +    # wondering what the available values are. Can there be multiple
> +    # categories?
> not a bad idea

I think it's essential.

> +    # We are pulling keywords from the title of the document.
> +    # We will have to come up with a better approach.
> +    <keywords created="20010315">assembly</keywords>
> +    <keywords created="20010315">howto</keywords>
> +    <keywords created="20010315">linux</keywords>
> +
> +    <description created="20010315">
> +       This is the Linux Assembly HOWTO, version &version;. This
> +       document describes how to program in assembly language using
> +       free programming tools, focusing on development for or from
> +       the Linux Operating System, mostly on IA-32 (i386) platform.
> +       Included material may or may not be applicable to other
> +       hardware and/or software platforms.
> +    </description>
> +
> +    # Are you working from the list established in the latest omf
> +    # specification? If so, good. I also just asked for a new value,
> +    # "Quick Reference" since the LDP is going to start working on a
> +    # series of them. Someday.
> would this be a new TYPE? again see
> http://www.ibiblio.org/osrt/omf/omf_elements

Yes, it would. Also, I want to do away with "mini-howto" for various
reasons I've expounded upon many times. Shall I go through them again,
or are you all sick of it? :-)

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                   da...@lu...
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

All parts should go together without forcing.  You must remember that the parts
you are reassembling were disassembled by you.  Therefore, if you can't get
them together again, there must be a reason.  By all means, do not use a hammer.
		-- IBM maintenance manual, 1925