[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tags (searching)
On Jun 13, 4:22pm, Gregory Leblanc wrote:
> Subject: RE: Tags (searching)
> > -----Original Message-----
> > From: Greg Ferguson [mailto:[email protected]]
> > Sent: Tuesday, June 13, 2000 4:10 PM
> > To: Gary Preckshot; LDP; [email protected]
> > Subject: Re: Tags (searching)
> >
> > On Jun 13, 2:13pm, Gary Preckshot wrote:
> > > Subject: Re: Tags (searching)
> > > Greg Ferguson wrote:
> > >
> > > >
> > > > Once AGAIN I want to re-interate...
> > > >
> > > > 1) There is a tag/field/structured search capability that
> > > > is near completion -- the OMF metadata framework.
> > > >
> > > > Please see http://metalab.unc.edu/osrt/omf/
>
> Hmm, that's significantly cooler than I'd thought that it was.
> What's the current status on this project?
Paul Jones can fill you/us in, or someone from his team. It's pretty
slick.
> Has anybody looked at a way to automatically update/create this
> information from the documents when they are submitted to the LDP?
That's the goal. I have a parsing engine, but as I mentioned it
needs work, and I/we still need to iron out some details with the
OMF folks (Paul's team) as to submittal.
> [snip]
> > btw, (side-note) there is a DocBook "lite" or "Simplified" DocBook
> > XML DTD that is under development -
> > http://nwalsh.com/docbook/simple/index.html
> > Not much to it; chops the DTD down to 104 elements (from 300+).
>
> I've taken a look at it, and I don't see any advantages to using that
> instead of DocBook.
I agree. I just thought I'd make mention of it.
> > > After all, DocBook Articles are not HOWTOs.
> >
> > Why not? What's missing? Or are you saying <article>
> > embodies too much "freedom" for a howto?
>
> That was the impression that I got. I'm still not completely decided
> on whether or not a template can fulfill the requirements for
> guiding authors to building a good document.
I understand. It's certainly a possible concern.
> [...snip...]
>
> > To recap :
> >
> > - I agree with stating that deprecated tags should not be used.
> >
> > - I agree with *guiding* the author via templates and examples
> > on how certain tags should be used/implemented. This can and
> > should be made very clear.
> >
> > - I agree with stating how/why certain tags should be *included*
> > and for what purpose (ie searching). The author then is
> > clued into the benefit of following the guidelines and template.
> >
> > - I am against proposing any sort of limiting tag set beyond
> > the exclusion of deprecated tags. Let the DTD control that (and
> > the display/presentation controlled via a DSSSL
> > customization layer).
>
> How strong do we make the templates, assuming that they are enough?
> Do we do something like the GDP did, and go in and hack up work that
> people have done because it differs from the template? That's clearly
> bad, and they got stung. How do we make a template that's HELPFUL
> to the authors, and doesn't restrict them?
I didn't say it would be easy ;-). If we do a decent job, and cover
90% (or so) of what we want/need to have covered in the template
we'll be in excellent shape.
Our authors at SGI are given a set of templates dependant upon what
env. they wish to work in (Adobe framemaker or the Adept SGML
editor). I would say that even for a new author, we've got upwards
of 95% of the possible cases/questions/scenarios covered in the
templates. However, there always seems to be one or two questions
a week that get fired off to our "tech support"-type mailing list
that deals with "how do I do this", or "is this the correct way to...".
Oh, and we've been at this for a long time. The templates
have been molded/shaped/iterated countless time.
The point I'm trying to make is that we are here to help.
ldp-docbook, ldp-discuss, the mail archives, etc..we've got
quite a few resources to help assist the authors. We need
to respond to feedback, shape the template and assist whenever
needed.
> Greg
Greg (couldn't resist doing that...)
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]