OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: DOCBOOK: metadata


Dave Pawson's response raises an interesting question for
the DocBook Technical Committee.  Does the Committee intend
to always keep the SGML and XML versions of DocBook DTD
equivalent?  If so, then that will pretty much eliminate
emerging XML standards as part of the solution set.
That would leave elements and attributes for metadata
inside the content, and ID as a way to associate
external metadata.

bobs

> From: Dave Pawson <daveP@dpawson.freeserve.co.uk>
> 
> At 07:44 PM 6/29/01, Michael Sabrio wrote:
> >The DocBook Tech Committee would like your input on a couple of
> >issues related to metadata.
> >
> >HP (like everyone else?) is beginning to create and manage chunks
> >of DocBook at levels below the section element.  For example,
> >we're creating procedure and example elements that we'd like to
> >manage separately from any higher-level elements that use them.
> >Any chunks we manage separately need to allow associated metadata.
> >
> >Except for some of the common attributes, however, the primary
> >DocBook containers for metadata are the *info elements, such as
> >sectioninfo, which holds metadata for a section element.  But the
> >*info elements are not allowed in elements below the section
> >level.
> >
> >(1) So the first question is: how should we associate metadata
> >with elements below the section level?  Should we do an element-
> >by-element review and add an info-like container to the ones that
> >need it?  Should we add some kind of pointer to or from separate
> >structures?
> >
> >(2) Second, as long as we're talking about metadata, should we do
> >anything to rationalize metadata in DocBook?
> 
> Give Norm a headache is the crude answer (sorry Norm).
> The intro is to use namespace seperation.
> Then pick your metadata content format (simple/rdf/dc/combination),
> Then point at the container/element about which you are talking..
>    with xpointer?
> Then find a reasonable place to put it, internal to the same file,
> externally, referenced from the parent of the 'chunk' or whatever,
> then sit back and pick holes in your solution.
> 
>   E.g. What if I tear it apart even further? I'll lose my metadata.
> 
> Then think about the glue to hold the chunks together and frown
> over xinclude or fragment interchange.
> 
> Iterate twice, ensuring you don't document your first solutions,
> in case someone makes you implement it,
> then sit down and do it for real.
> 
> This isn't helping is it?
>    I *think* this is the way that W3C are pointing, but its still
> over the horizon to some extent, certainly in terms of apps that
> would support it.
> 
> Regards DaveP
> 
> 
> 
> 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC