scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] Relations with OMF

[Dan M. <da...@ea...>]

On Fri, 27 Apr 2001, Eric Bischoff wrote:

> Speaking about this, one of the concerns at KDE was "how do we extract OMF 
> data out of our docbook files?". We did not wish to store the OMF 
> meta-information in a separate file. So the idea so far is:
> - to automatically extract DocBook meta-information which has OMF equivalent
> - to store OMF meta-information which has no DocBook equivalent (like the 
> position in the categories tree) in the DocBook file, using XML namespace to 
> differentiate it from plain DocBook, then to extract this information as well.

In the long term, I think we want to have the OMF elements added to
DocBook.  (You may recall that Norman Walsh thought this was a good idea
at the O'Reilly Summit.)  This way authors would only maintain one
file.  For the sake of maintaining databases and such, we may still
generate OMF files, but that is not of significance to the document
authors.

Before we can do this right, we have to stablize ScrollKeeper and the OMF
DTD to some extent.  Then we need to have the new tags added to
DocBook.   This takes a while, so I was planning on just using seperate
OMF files in the interim.

Your suggestion of adding tags which have their own namespace inside of a
DocBook document is interesting.  If we did this, would the document still
be a valid DocBook document which can be parsed by any standard DocBook
tool?  My impression was that it would not, but you know much more about
this than I do.  Or perhaps I am misundestanding what you mean.

Dan

Re: [Scrollkeeper-devel] Relations with OMF

[<las...@Su...>]

> Speaking about this, one of the concerns at KDE was "how do we extract OMF
> data out of our docbook files?". We did not wish to store the OMF
> meta-information in a separate file. So the idea so far is:
> - to automatically extract DocBook meta-information which has OMF equivalent
> - to store OMF meta-information which has no DocBook equivalent (like the
> position in the categories tree) in the DocBook file, using XML namespace to
> differentiate it from plain DocBook, then to extract this information as well.
> 

I think some support for automatic extraction from DocBook has been
discussed on ldp-meta and even something has been implemented. It is
called db2omf, the author says it has been added to the CVS, but I
couldnt find it. You might want to check their web site, mailing list
and get in contact with the author. The OMF web site and mailing list is
available from scrollkeeper.sourceforge.net.

Laszlo

Re: [Scrollkeeper-devel] Relations with OMF

[Eric B. <e.b...@no...>]

Le Friday 27 April 2001 09:49, Dan Mueth a =E9crit :
>
> I think Greg Leblanc is, in name, the active maintainer of the DTD now.=
  I
> think he has some work to do ;)  I think he's quietly lurking on both o=
f
> these mailing lists.  (Greg - are you here?)
>
> We definitely need to work with the OMF group more, not only on the DTD=
,
> but possibly on the OMF specification itself.  I need to look over your
> emails in the last couple days more carefully to understand exactly wha=
t
> belongs in the OMF and what we consider as ScrollKeeper-specific
> extensions.
>
> BTW: I raised a handful of issues which seemed at the time to be
> inconsistancies and/or ambiguities in the spec and DTD on ldp-meta some
> time ago.  I think those issues are still unresolved, and may be a good
> place to begin.

Speaking about this, one of the concerns at KDE was "how do we extract OM=
F=20
data out of our docbook files?". We did not wish to store the OMF=20
meta-information in a separate file. So the idea so far is:
- to automatically extract DocBook meta-information which has OMF equival=
ent
- to store OMF meta-information which has no DocBook equivalent (like the=
=20
position in the categories tree) in the DocBook file, using XML namespace=
 to=20
differentiate it from plain DocBook, then to extract this information as =
well.

> I would recommend starting a thread on ldp-meta for each of the OMF
> elements to review whether the spec is complete, unambiguous, and that =
the
> DTD is consistant with the spec.
>
> Bob - Any help you can offer to help move things along would be
> appreciated :)
>
> Dan

--=20
+----------------------------------------------------------------------+
| =C9ric Bischoff                              mailto:e.b...@no... =
|
+----------------------------------------------------------------------+

Re: [Scrollkeeper-devel] Relations with OMF

[Dan M. <da...@ea...>]

On Fri, 27 Apr 2001, Bob Stayton wrote:

> It sounds like the ScrollKeeper project needs to 
> work with OMF to settle these DTD issues.  Kendall
> responded, but is no longer working on OMF.  
> Do the SK developers already have a contact at
> OMF to work with, or should I (or someone else)
> initiate something?  Through the ldp-meta mailing
> list (which I'm on, but don't see much traffic)?

I think Greg Leblanc is, in name, the active maintainer of the DTD now.  I
think he has some work to do ;)  I think he's quietly lurking on both of
these mailing lists.  (Greg - are you here?)

We definitely need to work with the OMF group more, not only on the DTD,
but possibly on the OMF specification itself.  I need to look over your
emails in the last couple days more carefully to understand exactly what
belongs in the OMF and what we consider as ScrollKeeper-specific
extensions.

BTW: I raised a handful of issues which seemed at the time to be
inconsistancies and/or ambiguities in the spec and DTD on ldp-meta some
time ago.  I think those issues are still unresolved, and may be a good
place to begin.

I would recommend starting a thread on ldp-meta for each of the OMF
elements to review whether the spec is complete, unambiguous, and that the
DTD is consistant with the spec.

Bob - Any help you can offer to help move things along would be
appreciated :)

Dan

[Scrollkeeper-devel] Relations with OMF

[Bob S. <bo...@sc...>]

It sounds like the ScrollKeeper project needs to 
work with OMF to settle these DTD issues.  Kendall
responded, but is no longer working on OMF.  
Do the SK developers already have a contact at
OMF to work with, or should I (or someone else)
initiate something?  Through the ldp-meta mailing
list (which I'm on, but don't see much traffic)?

bobs
Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The Santa Cruz Operation, Inc.              fax:   (831) 429-1887
                                            email: bo...@sc...

Re: [Scrollkeeper-devel] Re: group part of URN

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

On Thu, Apr 26, 2001 at 02:21:28PM +0200, Eric Bischoff wrote:
> Le Thursday 26 April 2001 14:01, László Kovács a écrit :
> > Eric Bischoff wrote:
> > > Le Tuesday 24 April 2001 11:51, László Kovács a écrit :
> > > > :-) As far as Sun is concerned Scrollkeeper's primary purpose is to
> > > > support the Gnome Desktop Help.
> > >
> > > Hey? We at KDE are starting to think about scrollkeeper integration as
> > > well.
> >
> > Ah, sorry. Scrollkeeper is very platform independent, it does not have
> > anything platform specific in it. So integration with KDE should be no
> > problem.
> 
> In fact I believe Cornelius is quickly progressing with his tests. But he 
> might be speaking about them better than I can.

I am also committed to having all LDP documents available in sk.
Wow, all of us seem to be working together. Nice.

-- 
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

To err is human -- to blame it on a computer is even more so.

Re: [Scrollkeeper-devel] URN as identifier

[Kendall C. <ke...@mo...>]

>>>>> "bob" == Bob Stayton <bo...@sc...> writes:

  >> From: Kendall Clark <ke...@mo...>
  bob> Hi Kendall, It was very helpful to hear from you. Are you still
  bob> the maintainer of the OMF DTD?

No technically, though I forget who took it over (haven't heard
anything since then).
 
   bob> Actually, Dublin Core has done just that with the element
  bob> qualifiers they published 2000-07-11.  They are described in
  bob> <http://dublincore.org/documents/dcmes-qualifiers/>.  For the
  bob> <relation> element, they have:

  bob>   Is Version Of Has Version Is Replaced By Replaces Is Required
  bob>   By Requires Is Part Of Has Part Is Referenced By References
  bob>   Is Format Of Has Format

Yeah, these are nicely general; of course, SK and OMF still needs
(together or separately) figure out what these will mean in our
domain, how and when to use them, etc.

  bob> The one that caught my eye was "Is Version Of", since that
  bob> seems to capture the relation between a given document and the
  bob> seriesID.

Yes.

  bob> The question is then: How is this encoded in an OMF metadata? I
  bob> notice that the OMF <relation> element already has a "status"
  bob> attribute by virtue of the core attribute set in the DTD.  It
  bob> would seem we could just assign a specific value for the status
  bob> attribute.  For example:

  bob> <relation status="IsVersionOf"
  bob> url="seriesID-expressed-as-uri"/>

I'd prefer something like:

    <relation [dc-namespace]:type="IsVersionOf" uri="..." />

One thing that someone needs to do re: OMF is fix the URL/URL
ambiguity in the spec and the DTD. I favor using URL only when there's
a shared expectation that something is fetchable.

  bob> This means the document connected to this OMF <resource> is a
  bob> version of the seriesID.

Yeah, but what does "version of the seriesID" mean? It could be an
item in a revision history. Is that what you mean?

IsVersionOf could also just as well mean "this resource is a shorter,
excerpted version of this other resource over here".

  bob> Right.  To quote from the Dublin Core qualifiers document:

  bob> "It is expected that implementors will develop additional
  bob> qualifiers for use within local applications or specific
  bob> domains. Such qualifiers may not be understood by other
  bob> applications."

  bob> We could make it more SK or OMF specific by saying:

  bob> <relation status="omf-series-id"
  bob> url="seriesID-expressed-as-uri"/>

Yes, and at the risk of being a redundant doof, I think someone needs
to specify the meaning and use of the DC qualifiers *in the OMF and SK
context*, as well as any further OMF/SK-specific specifiers.

OMF needs some RDDL work done for all this meta-schema documentation.

Kendall
-- 
THIS MACHINE KILLS FASCISTS		http://monkeyfist.com/

Re: [Scrollkeeper-devel] structure of extracted index page

[<las...@Su...>]

>   I don't understand why, this computation has nothing Gnome specific
> int it !
:-) Sorry Daniel. I was just thinking loudly. You are right, it is not
Gnome specific, I was wrong. It will need any Scrollkeeper dependant
browser to generate the IDs in the same way as Scrollkeeper does it.
Which might be a problem if the browser is already implemented and it is
just integrated with Scrollkeeper. 

Thanks for the help,
 
Laszlo

Re: [Scrollkeeper-devel] structure of extracted index page

[Daniel V. <vei...@re...>]

On Thu, Apr 26, 2001 at 02:03:57PM +0100, L=E1szl=F3 Kov=E1cs wrote:
> This could be a good idea. But it might make Scrollkeeper Gnome
> dependent.

  I don't understand why, this computation has nothing Gnome specific
int it !

  I really don't understand your framework, please detail all the pieces
because it's getting frustrating ... All I understand is that at the
beginning there is a single docbook (XML) file and then multiple HTML=20
views are generated, please exaplin the different paths of the processing
(unless you already wrote it in some pages I can read).

Daniel

--=20
Daniel Veillard      | Red Hat Network http://redhat.com/products/network=
/
vei...@re...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: [Scrollkeeper-devel] structure of extracted index page

[Daniel V. <vei...@re...>]

On Thu, Apr 26, 2001 at 01:47:28PM +0100, Mary Dwyer wrote:
> hi Daniel
>=20
> I am somewhat confused on this issue too. I sent a mail earlier today, =
that you=20
> may have not received, which relates to this (see attached).
>=20
> The main point is the problem of having scrollkeeper generating ids rel=
ating to=20
> the original document. Specifically:
> from what I understand the convertor at run time generates ids where re=
quired=20
> (using generate-id() ).  However,  I don't believe scrollkeeper=20
> can predict what these ids will be because:
> 1) scrollkeeper may use a different convertor to the 'run-time' convert=
or.
> 2) even if the same convertor is used the w3.org description indicates =
that=20
>   "An implementation is under no obligation to generate the
>    same identifiers each time a document is transformed."
>    see http://www.w3.org/TR/xslt#function-generate-id

  Right I know.
  I could change libxslt to actually always generate the same ID
based on the trick described in my last mail to L=E1szl=F3 . But it would
be a bit slower (not noticeable IMHO) and a feature dependant on libxslt
specific implementation.

Daniel

--=20
Daniel Veillard      | Red Hat Network http://redhat.com/products/network=
/
vei...@re...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: [Scrollkeeper-devel] structure of extracted index page

[<las...@Su...>]

Daniel Veillard wrote:

>   Use some property of the input element to generate this ID.
> Example:
> 
> <doc>
>      <row/>
>      <row/>
>      <row>
>           <para/>
>           <colum/>
>           <colum/>
>           <colum/>
>           <colum>
>               <element_without_ID/>
>           </colum>
> ...
> 
> Associate it the following ID: SK_3_5_1 (child sequence when going from the
> root).
> Both programs would compute the same ID since it's based on the structure
> of the input document (shared). This is based on the child sequence mechanism
> of XPointer.
> 
> problem: it doesn't resist well to changes in the input, but in this case
>          I assume it's not a problem.
> 
> Daniel
> 

This could be a good idea. But it might make Scrollkeeper Gnome
dependent. Unless we come up with a common stylesheet that Scrollkeeper
exports and suggests to be used by whatever rendering mechanism is
implemented in the browser. It still might be a too tight connection
though.

Laszlo

Re: [Scrollkeeper-devel] structure of extracted index page

[Daniel V. <vei...@re...>]

On Thu, Apr 26, 2001 at 01:47:47PM +0100, L=E1szl=F3 Kov=E1cs wrote:
> > Did i missed something ?
>=20
> Yes, we have two systems parsing the same document (scrollkeeper and
> gnome-db2html[2|3]) and they can cooperate only if they generate the
> same "unique" id. I think this is our problem as this seems to be
> impossible.

  Use some property of the input element to generate this ID.
Example:

<doc>
     <row/>
     <row/>
     <row>
	  <para/>
          <colum/>
          <colum/>
          <colum/>
          <colum>
	      <element_without_ID/>
	  </colum>
...

Associate it the following ID: SK_3_5_1 (child sequence when going from t=
he
root).
Both programs would compute the same ID since it's based on the structure
of the input document (shared). This is based on the child sequence mecha=
nism
of XPointer.

problem: it doesn't resist well to changes in the input, but in this case
	 I assume it's not a problem.

Daniel


--=20
Daniel Veillard      | Red Hat Network http://redhat.com/products/network=
/
vei...@re...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: [Scrollkeeper-devel] structure of extracted index page

[<mv...@df...>]

> Yes, we have two systems parsing the same document (scrollkeeper and
> gnome-db2html[2|3]) and they can cooperate only if they generate the
> same "unique" id. I think this is our problem as this seems to be
> impossible.

Right, this is important, and needs to be solved. I guess scrollkeeper
would need to guess the result of gnome-db2html[2|3]? Can we make the
output from gnome-db2html3 be dependable?

Martin

Re: [Scrollkeeper-devel] structure of extracted index page

[Mary D. <Mar...@Su...>]

hi Daniel

I am somewhat confused on this issue too. I sent a mail earlier today, that=
 you=20
may have not received, which relates to this (see attached).

The main point is the problem of having scrollkeeper generating ids relatin=
g to=20
the original document. Specifically:
from what I understand the convertor at run time generates ids where requir=
ed=20
(using generate-id() ).  However,  I don't believe scrollkeeper=20
can predict what these ids will be because:
1) scrollkeeper may use a different convertor to the 'run-time' convertor.
2) even if the same convertor is used the w3.org description indicates that=
=20
  "An implementation is under no obligation to generate the
   same identifiers each time a document is transformed."
   see http://www.w3.org/TR/xslt#function-generate-id

Is this a correct assumption or have I misunderstood this (which is entirel=
y=20
possible :-) )

cheers
Mary

> Date: Thu, 26 Apr 2001 08:32:35 -0400
> From: Daniel Veillard <vei...@re...>
> To: L=E1szl=F3 Kov=E1cs <las...@Su...>
> Cc: vei...@re..., Dan Mueth <da...@ea...>, Mary Dwyer=20
<Mar...@Su...>, scr...@li...,=20
gno...@gn...
> Subject: Re: [Scrollkeeper-devel] structure of extracted index page
> Mime-Version: 1.0
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
> User-Agent: Mutt/1.2.5i
>=20
> On Thu, Apr 26, 2001 at 12:13:25PM +0100, L=E1szl=F3 Kov=E1cs wrote:
> > > > Yes, sections with no IDs are ignored  during TOC extraction.
> > >=20
> > >   Hum, this should probably be improved ...
>=20
>   That is sure.
>=20
> > > C.f. my other mail for a possible technical solution.
>=20
>   Now whether XPointer can help w.r.t. the addressability then it really
> depends what need to be addressed.
>=20
> > Are you talking about the XPointer email? I dont understand how that
> > helps us here. Our problem is that if a section does not have a unique
> > id then Scrollkeeper and gnome-db2html[2|3] can jump there only if they
> > generate an id to this section which is the same in both Scrollkeeper
> > and the convertor.
>=20
>   What do you mean by jump here:
>     - if the here is an XML document, then I assume the document is
>       handled by libxml and hence XPointer can be used
>     - if the here is an HTML document, then XSLT has a=20
>       generate-id() function which can be used to generate a unique ID
>       for this element, and pointing is also possible using the existing
>       #name framework.
>=20
> Did i missed something ?
>=20
> Daniel
>=20
> --=20
> Daniel Veillard      | Red Hat Network http://redhat.com/products/network=
/
> vei...@re...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

~ I speak for myself, not for my employer ~
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D
Mary Dwyer
Desktop Applications & Middleware Grp
Sun Microsystems Ireland
Tel: +353-1-8199222 (xt 19222)
Fax: +353-1-8199078
email: mar...@ir...
=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D=
-=3D

Re: [Scrollkeeper-devel] structure of extracted index page

[<las...@Su...>]

Daniel Veillard wrote:
> 
>   What do you mean by jump here:
>     - if the here is an XML document, then I assume the document is
>       handled by libxml and hence XPointer can be used
>     - if the here is an HTML document, then XSLT has a
>       generate-id() function which can be used to generate a unique ID
>       for this element, and pointing is also possible using the existing
>       #name framework.
> 
> Did i missed something ?

Yes, we have two systems parsing the same document (scrollkeeper and
gnome-db2html[2|3]) and they can cooperate only if they generate the
same "unique" id. I think this is our problem as this seems to be
impossible.

Laszlo

Re: [Scrollkeeper-devel] structure of extracted index page

[Daniel V. <vei...@re...>]

On Thu, Apr 26, 2001 at 12:13:25PM +0100, L=E1szl=F3 Kov=E1cs wrote:
> > > Yes, sections with no IDs are ignored  during TOC extraction.
> >=20
> >   Hum, this should probably be improved ...

  That is sure.

> > C.f. my other mail for a possible technical solution.

  Now whether XPointer can help w.r.t. the addressability then it really
depends what need to be addressed.

> Are you talking about the XPointer email? I dont understand how that
> helps us here. Our problem is that if a section does not have a unique
> id then Scrollkeeper and gnome-db2html[2|3] can jump there only if they
> generate an id to this section which is the same in both Scrollkeeper
> and the convertor.

  What do you mean by jump here:
    - if the here is an XML document, then I assume the document is
      handled by libxml and hence XPointer can be used
    - if the here is an HTML document, then XSLT has a=20
      generate-id() function which can be used to generate a unique ID
      for this element, and pointing is also possible using the existing
      #name framework.

Did i missed something ?

Daniel

--=20
Daniel Veillard      | Red Hat Network http://redhat.com/products/network=
/
vei...@re...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: [Scrollkeeper-devel] Re: group part of URN

[Eric B. <e.b...@no...>]

Le Thursday 26 April 2001 14:01, L=E1szl=F3 Kov=E1cs a =E9crit :
> Eric Bischoff wrote:
> > Le Tuesday 24 April 2001 11:51, L=E1szl=F3 Kov=E1cs a =E9crit :
> > > :-) As far as Sun is concerned Scrollkeeper's primary purpose is to
> > > support the Gnome Desktop Help.
> >
> > Hey? We at KDE are starting to think about scrollkeeper integration a=
s
> > well.
>
> Ah, sorry. Scrollkeeper is very platform independent, it does not have
> anything platform specific in it. So integration with KDE should be no
> problem.

In fact I believe Cornelius is quickly progressing with his tests. But he=
=20
might be speaking about them better than I can.

--=20
+----------------------------------------------------------------------+
| =C9ric Bischoff                              mailto:e.b...@no... =
|
+----------------------------------------------------------------------+

Re: [Scrollkeeper-devel] Re: group part of URN

[<las...@Su...>]

Eric Bischoff wrote:
> =

> Le Tuesday 24 April 2001 11:51, L=E1szl=F3 Kov=E1cs a =E9crit :
> > :-) As far as Sun is concerned Scrollkeeper's primary purpose is to
> > support the Gnome Desktop Help.
> =

> Hey? We at KDE are starting to think about scrollkeeper integration as =
well.
> =

> --
> +----------------------------------------------------------------------=
+
> | =C9ric Bischoff                              mailto:e.bischoff@noos.f=
r |
> +----------------------------------------------------------------------=
+

Ah, sorry. Scrollkeeper is very platform independent, it does not have
anything platform specific in it. So integration with KDE should be no
problem.

Laszlo

Re: [Scrollkeeper-devel] Re: group part of URN

[Eric B. <e.b...@no...>]

Le Tuesday 24 April 2001 11:51, L=E1szl=F3 Kov=E1cs a =E9crit :
> :-) As far as Sun is concerned Scrollkeeper's primary purpose is to
> support the Gnome Desktop Help.

Hey? We at KDE are starting to think about scrollkeeper integration as we=
ll.

--=20
+----------------------------------------------------------------------+
| =C9ric Bischoff                              mailto:e.b...@no... =
|
+----------------------------------------------------------------------+

Re: [Scrollkeeper-devel] structure of extracted index page

[<las...@Su...>]

Daniel Veillard wrote:
> =

> On Thu, Apr 26, 2001 at 10:29:42AM +0100, L=E1szl=F3 Kov=E1cs wrote:
> > > Laszlo - Does this all sound correct based on your experience?  How=
 do you
> > > handle sections without id's in ScrollKeeper's TOC extraction?  Do =
you
> > > ignore those sections or id them in the same way as db2html?
> > Yes, sections with no IDs are ignored  during TOC extraction.
> =

>   Hum, this should probably be improved ...
> C.f. my other mail for a possible technical solution.
> =

> Daniel

Are you talking about the XPointer email? I dont understand how that
helps us here. Our problem is that if a section does not have a unique
id then Scrollkeeper and gnome-db2html[2|3] can jump there only if they
generate an id to this section which is the same in both Scrollkeeper
and the convertor. I am not sure how could XPointer help us in this
case. I think the examples you gave described how to identify one or
more subparts of the xml doc. But as far as I understand we still need
something to uniquely identify the subpart we are going for to use the
XPointer mechanism and we dont have uniqueness assured. Unless I
misunderstand something badly which is possible as I didnt spend a huge
amount of time with XPointer yet.

Laszlo

Re: [Scrollkeeper-devel] structure of extracted index page

[Daniel V. <vei...@re...>]

On Thu, Apr 26, 2001 at 10:29:42AM +0100, L=E1szl=F3 Kov=E1cs wrote:
> > Laszlo - Does this all sound correct based on your experience?  How d=
o you
> > handle sections without id's in ScrollKeeper's TOC extraction?  Do yo=
u
> > ignore those sections or id them in the same way as db2html?
> Yes, sections with no IDs are ignored  during TOC extraction.

  Hum, this should probably be improved ...
C.f. my other mail for a possible technical solution.

Daniel

--=20
Daniel Veillard      | Red Hat Network http://redhat.com/products/network=
/
vei...@re...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: [Scrollkeeper-devel] structure of extracted index page

[Daniel V. <vei...@re...>]

On Thu, Apr 26, 2001 at 02:24:47AM -0500, Dan Mueth wrote:
> 
> On Thu, 26 Apr 2001, Daniel Veillard wrote:
> 
> > On Wed, Apr 25, 2001 at 10:44:30PM -0500, Dan Mueth wrote:
> > > The other possibility is that instead of trying to refer to an anchor in
> > > the generated HTML, we try to refer to the position in the XML document.  
> > > I really don't know how this would work exactly, since I am not very
> > > familiar with libxml, but it may be possible.  (DV?)
> > 
> >   I'm afraid I didn't follow the discussion here (sorry !), the best
> > way to get a technical  answer from me is to give me a practical example
> > (what's your input, how it's processed, what's the result, why it fails),
> > and then I can use what I know both from the specs and the code to get
> > this answer precisely and quickly,
> 
> Ok.  Let me give this a shot...
> 
> <disclaimer>
> The DTD represented in this email is fictional and any similarity
> with a real DTD is purely coincidental.
> </disclaimer>
> 
> <sect1>
>   <para>
>     This is a sentence.
>   </para>
>   <indexterm>
>     <primary>
>       Sentences
>     </primary>
>   </indexterm>
>   <para>
>     This is another sentence.
>   </para>
> </sect1>
> 
> When this is converted to HTML, we will get an index at the end of the
> document which has a link from an item called "Sentences" to the location
> of the indexterm element above: between the two paragraphs.  Populating
> our document with indexterms yields a helpful index at the end of the
> document :)
> 
> We would like ScrollKeeper to keep an XML data file describing the
> index.  It should list all of the index terms and where they link into the
> document.
> 
> The thing I am not sure about is how we "anchor" the links into the
> document.  If the indexterm had a unique id attribute, we could use
> that.  But our DTD does not require the id attribute be used.
> 
> Is there a nice way we could have an XML representation of the index which
> somehow specifies the anchors for the index term links so that a browser
> (such as the help browser in Nautilus) can link from index terms to
> locations in the XML document?

  If you want to point into the XML then you need to use XPointer,
if you had an ID on the element, say "sentencedef", then the simple
way to addres the subpart is

     #sentencedef

if you don't have such an ID in this case you can use the structured
access method of XPointer in this case one such pointer could be:

     #xpointer(/sect1[1]/indexterm[1]/primary[1])

Libxml has an XPointer implementation

orchis:~/XML -> cat tst.xml
<sect1>
  <para>
    This is a sentence.
  </para>
  <indexterm>
    <primary>
      Sentences
    </primary>
  </indexterm>
  <para>
    This is another sentence.
  </para>
</sect1>

orchis:~/XML -> ./testXPath -xptr -i tst.xml "xpointer(/sect1[1]/indexterm[1]/primary[1])"
Object is a Node Set :
Set contains 1 nodes:
1  ELEMENT primary
orchis:~/XML -> 

  XPointer is not (yet) widely deployed, I just happen to be the co-chair
of the working group defining it at W3C, you can get the spec at
    http://www.w3.org/TR/xptr

and I can of course answer questions about it.

  In practice, getting IDs is better because it's more resilient to changes
another improvement would be to have one term per primary tag like this
<primary>sentence</primary>
then a very resilent XPointer would be:

  #xpointer(//indexterm/primary[. = "sentence"])

Basically it instructs to search all indexterm in the document, then
look for primary children and extract the ones where the content is
 "sentence"

  All those queries are actually XPath expressions (used in XSLT too),
you can get more informations at :
   - a generic presentation on XPointer
     http://daniel.veillard.com/Talks/9912XPointer/Overview.html

   - the W3C page on XPointer (at the bottom of the page)
     http://www.w3.org/XML/Linking.html

   - XPointer libxml interfaces:
    http://xmlsoft.org/html/libxml-xpointer.html

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
vei...@re...  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: [Scrollkeeper-devel] structure of extracted index page

[Mary D. <Mar...@su...>]

hi Dan

You're right - the nesting needs to be addressed and I like your suggestions.

I need to do some experimenting on the generating of ids for the "see" "see 
also" to find out the best way of implementing this.

many thanks for the feedback
cheers
Mary


> 
> 
> [removing gnome-doc-list from cc list since this email is getting into the
> internal guts of SK]
> 
> On Wed, 25 Apr 2001, Mary Dwyer wrote:
> 
> > Example:
> > 
> > <indexdoc>
> >    <indexentry linkid="idx-a1">Apple, Big, Green
> >    </indexentry>
> >    <indexentry linkid="idx-a2">Banana, Small
> >    </indexentry>
> >    <indexentry linkid="a1">Orange, Medium
> >    </indexentry
> >       
> >    etc. .......
> >    
> > </indexdoc>   
> 
> There is nesting information which is left out.  For example, if you also
> have "Apple, Big, Blue", the markup above does not reveal that your index
> looks like:
>   Apple
>       Big
>           Green  *
>           Blue   *
>   Banana
>       Small      *
>   Orange
>       Medium     *
> 
> I think it makes sense to put this into the XML file, since this is the
> way the data will typically be displayed and processed.  If SK does the
> work of sorting this out then things will be faster and easier for the
> help browsers.
> 
> Note that for <see> and <seealso>, they are actually creating links
> *within* the index, pointing to other parts of the index.  For these we
> can either describe their position by creating an id for them or by
> specifying the full index term they link to.  I'm not sure which is
> better, but introducing id's seems reasonable.
> 
> For example, one might use:
> 
> <indexdoc>
>   <primary>
>      <title>Apple</title>
>      <secondary>
>        <title>Big</title>
>        <tertiary>
>           <title linkid="idx-a1">Green</title>
>           <title linkid="idx-a3">Blue</title>
>           <seealso seeid="sa-1">New York City</seealso>
>        </tertiary>
>      </secondary>
>    </primary>
>    <primary>
>      <title>Banana</title>
>      <secondary>
>        <title linkid="idx-a2">Small</title>
>      </secondary>
>    </primary>
>    <primary>
>      <title id="sa-1" linkid="idx-a5">New York City</title>
>    </primary>
> </indexdoc>
> 
> or
> 
> <indexdoc>
>   <primary title="Apple">
>     <secondary title="Big">
>       <tertiary title="Green" linkid="idx-a1"/>
>       <tertiary title="Blue" linkid="idx-a3"/>
>       <seealso title="New York City" seeid="sa-1"/>
>     </secondary>
>   </primary>
>   <primary title="Banana">
>     <secondary title="Small" linkid="idx-a2"/>
>   </primary>
>   <primary title="New York City" id="sa-1" linkid="idx-a5">
>   </primary>
> </indexdoc>
> 
> So, here SK generated the id "sa-1" which is used to link to "New York
> City" in the index, while "idx-a5" is the id assigned to the index term by
> the author for linking from the index into the body of the document.
> 
> Does this seem reasonable?
> 
> Dan
> 
> 
> 
> _______________________________________________
> Scrollkeeper-devel mailing list
> Scr...@li...
> http://lists.sourceforge.net/lists/listinfo/scrollkeeper-devel

~ I speak for myself, not for my employer ~
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mary Dwyer
Desktop Applications & Middleware Grp
Sun Microsystems Ireland
Tel: +353-1-8199222 (xt 19222)
Fax: +353-1-8199078
email: mar...@ir...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: [Scrollkeeper-devel] structure of extracted index page

[<las...@Su...>]

> Laszlo - Does this all sound correct based on your experience?  How do you
> handle sections without id's in ScrollKeeper's TOC extraction?  Do you
> ignore those sections or id them in the same way as db2html?
Yes, sections with no IDs are ignored  during TOC extraction.

Laszlo

Re: [Scrollkeeper-devel] structure of extracted index page

[Dan M. <da...@ea...>]

On Thu, 26 Apr 2001, Daniel Veillard wrote:

> On Wed, Apr 25, 2001 at 10:44:30PM -0500, Dan Mueth wrote:
> > The other possibility is that instead of trying to refer to an anchor in
> > the generated HTML, we try to refer to the position in the XML document.  
> > I really don't know how this would work exactly, since I am not very
> > familiar with libxml, but it may be possible.  (DV?)
> 
>   I'm afraid I didn't follow the discussion here (sorry !), the best
> way to get a technical  answer from me is to give me a practical example
> (what's your input, how it's processed, what's the result, why it fails),
> and then I can use what I know both from the specs and the code to get
> this answer precisely and quickly,

Ok.  Let me give this a shot...

<disclaimer>
The DTD represented in this email is fictional and any similarity
with a real DTD is purely coincidental.
</disclaimer>

<sect1>
  <para>
    This is a sentence.
  </para>
  <indexterm>
    <primary>
      Sentences
    </primary>
  </indexterm>
  <para>
    This is another sentence.
  </para>
</sect1>

When this is converted to HTML, we will get an index at the end of the
document which has a link from an item called "Sentences" to the location
of the indexterm element above: between the two paragraphs.  Populating
our document with indexterms yields a helpful index at the end of the
document :)

We would like ScrollKeeper to keep an XML data file describing the
index.  It should list all of the index terms and where they link into the
document.

The thing I am not sure about is how we "anchor" the links into the
document.  If the indexterm had a unique id attribute, we could use
that.  But our DTD does not require the id attribute be used.

Is there a nice way we could have an XML representation of the index which
somehow specifies the anchors for the index term links so that a browser
(such as the help browser in Nautilus) can link from index terms to
locations in the XML document?

I hope this was clearer.

Dan