Re: document referencing through book.xml [was: draft howto dtd]

[Ivelin Ivanov <iv...@apache.org>]

Steven,

Is our discussion with Rob relevant to your work?



Ivelin

----- Original Message -----
From: "David Crossley" <cr...@indexgeo.com.au>
To: <fo...@xml.apache.org>
Sent: Monday, May 27, 2002 8:58 PM
Subject: Re: draft howto dtd


> Hi Ivelin and Rob, i have an alert.
>
> I do not know how far they are progressed.
> However, Steven Noels and some of his colleagues
> are working a Cocoon facility that they referred to
> as directory-generator-on-steroids ... as a replacemnt
> for book.xml
>
> So what i am saying is ... Heads Up, be careful that
> you do not waste valuable effort. I am not saying
> that your discussion is not relevant.I have only
> skimmed through it and thought that i had better
> tell you about overlap.
>
> I think that there have been small discussions about
> their work on both cocoon-dev and forrest-dev
>
> Also i think that it would be a good idea for you
> to change the subject title of this thread.
> --David
>
> Ivelin Ivanov wrote:
> >
> > Rob,
> >
> > you guessed right, sorry I wasn't clear.
> > I meant that the reference to the book.xml files can be easily made
> > available to the other documents.
> > And yes your suggested syntax makes sence to me.
> >
> > <xsl:param name="bookDocument"/>
> > <xsl:variable
> >    name="book-xml"
> >    select="document($bookDocument)/book"/>
> >
> > Then referencing in documents can be as simple as:
> >
> > <link href="{book-xml/menu/menu-item[@id='howto-step1]/@href}'">
> >
> > or even
> >
> > <link href="{book-xml//*[@id='howto-step1]/@href}'">
> >
> > Provided ids are unique.
> >
> > That is when the documents are allowed to use xsl (why not?).
> >
> > If we prefer to keep documents strictly static, then your suggestion is
a
> > valid solution.
> > I would only prefer to use the attribute names as:
> >
> > <link href="http://good old method">
> >
> > and something like
> >
> > <link book-href="'howto-step1"/>
> >
> >
> > What do others think?
> >
> >
> > Ivelin
> >
> >
> >
> > ----- Original Message -----
> > From: "Robert Koberg" <ro...@koberg.com>
> > To: <fo...@xml.apache.org>
> > Sent: Monday, May 27, 2002 3:55 PM
> > Subject: Re: draft howto dtd
> >
> >
> > Hi again,
> >
> > A couple of things i want to mention after rereading this...
> >
> > the book.xml should have the cocoon folder-name so it can resolve to it
> > instead of the docroot, for example:
> >
> > <book id="f1" label="Cocoon" folder-name="cocoon">
> >   <menu id="f1234" label="Samples" folder-name="samples">
> >      <menu-item id="c3432" label="Samples Home" file-name="index.html"/>
> > etc...
> >
> > Also, I am thinking you meant the the book-xml param might be a string
> > with a relative or full path to the book.xml file??
> >
> > If so, then instead of:
> > <xsl:param name="book-xml"/>
> > use:
> > <xsl:param name="bookDocument"/>
> > <xsl:variable
> >    name="book-xml"
> >    select="document($bookDocument)/book"/>
> >
> > Does this make sense?
> >
> > -Rob
> >
> >
> > Robert Koberg wrote:
> >
> > > Hi Ivelin,
> > >
> > > Ivelin Ivanov wrote:
> > >
> > >> Good points.
> > >>
> > >> ----- Original Message -----
> > >> From: "Robert Koberg" <ro...@koberg.com>
> > >>
> > >>
> > >>> Hi,
> > >>>
> > >>> On the book.xml (menu/site-structure) and index.xml (content piece),
for
> > >>> example: why duplicate link's href values - if you had access to
> > >>> book.xml (the menu or site structure) you could reference links by
ID
> > >>> instead of a hard coded link. For example the content hard codes
links
> > >>> to faq.html or http://xml.apache.org/cocoon. Why not have th1?in
one
> > >>> location (book.xml) and refer to them? It would be nice to reuse the
> > >>> data provided by book.xml (perhaps even store more page level meta
info
> > >>> there?? show-toc, show-meta-data, show-on-nav - or at the folder
level:
> > >>> number-pages, show-on-nav - etc). Even better have book.xml be a
> > >>> representation of the entire site hierarchy. Then you can
recursviely
> > >>> build paths to documents. For all the good book.xml does it could be
> > >>> written straight into the XSLT (and included :).
> > >>>
> > >>
> > >>
> > >> Can you suggest a concrete (preferably standard) technique for
> > >> documents to
> > >> use links from within book.xml?
> > >>
> > > Sure. How about something like this:
> > >
> > > book.xml (I have an alternative if you are interested...)
> > > -----------------------------
> > > <book>
> > >   <menu id="f1234" label="Document Sample" folder-name="samples">
> > >      <menu-item id="c3432" label="Samples Home"
file-name="index.html"/>
> > >      <menu id="f6234" label="Pipelines" folder-name="pipelines">
> > >         <menu-item id="c7663" label="Pipeline 1"
> > > file-name="pipeline1.html"/>
> > >         <menu-item id="c8795" label="Pipeline 2"
> > > file-name="pipeline2.html"/>
> > >      </menu>
> > >   </menu>
> > > </book>
> > >
> > > a content XML, say the cocoon home page:
> > > -----------------------------
> > > <article>
> > >  <title>jdfghjdfgh jsdfjksd</title>
> > >  <para>Check out <link id="c8795">Pipeline 2</link> or go out to
> > > bubba's site to see this <link
> > > out="http://www.bubba.com/example.html">example</link>
> > > </article>
> > >
> > > <!-- perhaps all you need is <link id="c8795"/>  and the label or link
> > > text can come from the book.xml, see the XSLT below for clues how this
> > > could be done -->
> > >
> > > ============================
> > > If you can pass the XML (nodeset) in as a param then you would not
> > > need the XPath document function. In a primary XSLT you bring the
> > > top-level param for the above config XML:
> > > ---------
> > > <xsl:param name="book-xml"/>
> > > =======
> > > also make a key at the top-level for speed in accessing the correct
> > > menu{-item}:
> > > -------
> > > <xsl:key name="menu-id-key" match="menu | menu-item" use="@id"/>
> > > ========
> > > Then at some point you match a link:
> > > -------
> > > <xsl:template match="link">
> > > <!-- choose whether it is internal or external -->
> > >   <xsl:variable name="href">
> > >       <xsl:choose>
> > >         <xsl:when test="boolean(@id)">
> > >            <xsl:apply-templates select="$book-xml">
> > >               <xsl:with-param name="link_id" select="@id"/>
> > >            </xsl:apply-templates>
> > >         </xsl:when>
> > >         <xsl:when test="boolean(@out)">
> > >            <xsl:value-of select="@out"/>
> > >         </xsl:when>
> > >      </xsl:choose>
> > >   </xsl:variable>
> > >
> > >   <a href="{$href}">
> > >      <xsl:if test="boolean(@out)">
> > >         <xsl:attribute name="target">_blank</xsl:attribute>
> > >      </xsl:if>
> > >      <xsl:apply-templates/>
> > >   </a>
> > > </xsl:template>
> > >
> > > <!-- change contexts to the book-xml nodeset (so you can use the key
> > > and travel the XML) -->
> > > <xsl:template match="book">
> > >   <xsl:param name="link_id"/>
> > >   <xsl:apply-templates select="key('menu-id-key', $link_id)"
> > > mode="linker"/>
> > > </xsl:template>
> > >
> > > <!-- recurse over the path to the document and provide the path
info -->
> > > <!-- something like this - not tested -->
> > > <xsl:template match="menu-item | menu" mode="linker">
> > >   <xsl:apply-templates select="parent::menu"/>
> > >   <xsl:text>/<xsl:text>
> > >   <xsl:value-of select="@file-name"/>
> > > </xsl:template>
> > >
> > > <xsl:template match="menu-item | menu">
> > >   <xsl:apply-templates select="parent::menu"/>
> > >   <xsl:text>/<xsl:text>
> > >   <xsl:value-of select="@folder-name"/>
> > > </xsl:template>
> > >
> > >
> > >
> > >
> > >
> > >> It has been proposed that W3C Topic Maps can be useful.
> > >> http://www.gca.org/papers/xmleurope2000/papers/s11-02.html
> > >>
> > > have not looked too far into this :(
> > >
> > >>
> > >> How about using the document link tag like this:
> > >>
> > >> <link
href="document({$bookDocument})/menu/menu-item[@id='howto-step1'">
> > >>
> > > See above
> > >
> > >>
> > >> Where the bookDocument variable is passed in from the sitemap.
> > >> This will require that the document files are not plain xml files,
> > >> but xslt
> > >> files instead.
> > >>
> > > hmmm... why do they need to be XSLT? Can it be passed in as a nodeset
> > > to a top-level param, since we can't use the XPath document function
> > > to get it from the filesystem.
> > >
> > > best,
> > > -Rob
> > >
> > >> To keep things clean maybe the <link/> tag can be extended with
> > >> syntax like:
> > >>
> > >> <link href="book/howto-step1"/> or similar
> > >>
> > >>
> > >>
> > >>> I still don't see what is wrong with using import or include to
bring
> > >>> together many XSLTs into one. The cocoon way of performing multiple
> > >>> transformations seems like way too much work when you want to break
your
> > >>> XSLT into component pieces for easy reusability.
> > >>>
> > >>> I think you miss a *great deal* of the benefit of XSLT by not using
the
> > >>> document function and import/include. I can't seem to come up with a
> > >>> good way to do the things I want to do without them.
> > >>>
> > >>
> > >>
> > >> I agree that the map:aggregate in the sitemap is somewhat redundand.
> > >> What are its advantages over passing the components as parameters to
a
> > >> normal XSLT page
> > >> which includes them either through include/import or the document()
> > >> function.
> > >> The advantages that I see in the latter approach are that its
> > >> utilizing XML
> > >> standards.
> > >> It also allows use of namespaces in the aggregating document, allows
> > >> references to validation documents,
> > >> and everything else you can use in an XSLT document.
> > >> Additionally the link referencing suggested above is natural.
> > >>
> > >>
> > >> Cheers,
> > >>
> > >> Ivelin
> > >>
> > >>
> > >>
> > >>
> > >>> I would love clear, explicit documentation on how to do things that
are
> > >>> commonplace in regular XSLT but are to be avoided when using cocoon.
> > >>>
> > >>> best,
> > >>> -Rob
> > >>>
> > >>>
> > >>>
> > >>
> > >
> > >
> >
> >
> >
> >
> >
>
>

Re: http://www.openebook.org/ compliance?

[Ivelin Ivanov <iv...@apache.org>]

----- Original Message -----
From: "Steven Noels" <st...@outerthought.org>
To: <fo...@xml.apache.org>
Sent: Saturday, June 01, 2002 1:49 AM
Subject: RE: http://www.openebook.org/ compliance?


> > From: Ivelin Ivanov [mailto:ivelin@apache.org]
>
> > The xml markup appears to be a superset of document-v10.
> > Issues like resource referencing through a catalog of links have been
> > addressed.
> > (This is related to the issue Rob and I discussed recently.
> > The solution is
> > similar too, using ids for each link.)
>
> Seems like a mixture of XHTML and Dublin Core metadata to me. Ideally,
> we should have a pipeline that aggregates all documents and publishes
> them as one eBook 'pkg' document.

Correct. This is what I thought.
Another thing I like is that there are tons of publishing professionals
figuring out the presentation details, doing the usability research, etc. We
don't need to worry about it. Validating schemas, skins, etc. come for free
too.

At a first glance, it doesn't seem like an overbloated standard.
The major components of the OEBPS Package file look right:

Package Identity - A unique identifier for the OEBPS Publication as a whole.

Metadata - Publication metadata - (title, author, publisher, etc.).

Manifest - A list of files (documents, images, style sheets, etc.) that make
up the publication. The manifest also includes fallback declarations for
files of types not supported by this specification.

Spine - An arrangement of documents providing a linear reading order.

Tours - A set of alternate reading sequences through the publication, such
as selective views for various reading purposes, reader expertise levels,
etc.

Guide - A set of references to fundamental structural features of the
publication, such as table of contents, foreword, bibliography, etc.


>Interesting thought - does anyone has
> an eBook reading device on this list?


PalmOS and Windows CE devices can read eBooks with the right software.

eBook software:
http://publishing.about.com/cs/ebooksoftware/

You can download Acrobat eBook reader for free to read on your PC.
http://www.adobe.com/products/ebookreader/register.html

MS Word and Acrobat FrameMaker claim to be (soon) able to export/import Open
eBook docs.

eBook Software Capabilities: Pushing the Envelope
http://12.108.175.91/ebookweb/stories/storyReader$459




>
> </Steven>
>

RE: http://www.openebook.org/ compliance?

[Steven Noels <st...@outerthought.org>]

> From: Ivelin Ivanov [mailto:ivelin@apache.org]

> The xml markup appears to be a superset of document-v10.
> Issues like resource referencing through a catalog of links have been
> addressed.
> (This is related to the issue Rob and I discussed recently.
> The solution is
> similar too, using ids for each link.)

Seems like a mixture of XHTML and Dublin Core metadata to me. Ideally,
we should have a pipeline that aggregates all documents and publishes
them as one eBook 'pkg' document. Interesting thought - does anyone has
an eBook reading device on this list?

</Steven>

http://www.openebook.org/ compliance?

[Ivelin Ivanov <iv...@apache.org>]

I don't remember this being discussed here,
so I'll ask.

Have we considered compliance with the OpenBook initiative.
It appears to be a major undertaking in the publishing industry.
http://www.openebook.org/

The xml markup appears to be a superset of document-v10.
Issues like resource referencing through a catalog of links have been
addressed.
(This is related to the issue Rob and I discussed recently. The solution is
similar too, using ids for each link.)

Forrest can probably style just a subset of the markup for the web site.
However if the documents are stored as OpenBooks, then publishing in other
formats including printed media will be simpler. This is valuable especially
for documentation.

Thoughts?

Ivelin

book.xml [RE: document referencing through book.xml [was: draft howto dtd]]

[Steven Noels <st...@outerthought.org>]

Ivelin,

yes it is, but I'll need some consecutive time to package and submit
what we already have as a book.xml replacer. I'm working on it!

Sorry for holding things up, I promise I'll post soon!

</Steven>