Newbie: XML to XHTML, browsing subsets of the data at a time?

Discussion in 'XML' started by Bondo, Apr 4, 2007.

  1. Bondo

    Bondo Guest

    I'm just getting started with XSLT to see if it can solve my task at
    hand, and so far it looks really good. But I can't get my head around
    how to present only a subset of a large data set at a time in the
    browser.

    Everything must take place on the client. The user opens the data.xml
    file and, after the XSLT processing, sees the XHTML. Since the full
    data set in data.xml can be quite large, I'd like to offer a familiar
    Prev|1|2|3|...|Next type of page navigation. How can this be done?

    I've searched on the Internet, but found it remarkably quiet on the
    subject. Maybe I'm looking the wrong places. And perhaps it's not even
    an XSLT issue?

    The solution must support the mainstream browsers, not just IE.

    Thanks for your time,
    Joachim
     
    Bondo, Apr 4, 2007
    #1
    1. Advertising

  2. Bondo

    Guest

    On Apr 4, 10:34 am, "Bondo" <> wrote:
    > Everything must take place on the client. The user opens
    > the data.xml file and, after the XSLT processing, sees
    > the XHTML.


    Poor choice. XHTML is not supported by MSIE. Transforming
    on the client side should be avoided unless you know very
    well what you're doing.

    > Since the full data set in data.xml can be quite large,
    > I'd like to offer a familiar Prev|1|2|3|...|Next type of
    > page navigation. How can this be done?


    If you want to transfer the entire data.xml to client and
    transform it client-side, the question has nothing to do
    with XML, since it boils down to implementing some
    JavaScript-driven UI gimmick that would hide portions of
    the resulting document. comp.lang.javascript is ===> that
    way.

    > I've searched on the Internet, but found it remarkably
    > quiet on the subject. Maybe I'm looking the wrong places.
    > And perhaps it's not even an XSLT issue?


    Consider doing it the right way. Transform server-side,
    serve HTML 4.01 Strict.

    --
    Pavel Lepin
     
    , Apr 4, 2007
    #2
    1. Advertising

  3. Bondo

    Bondo Guest

    On Apr 4, 10:05 am, wrote:
    > On Apr 4, 10:34 am, "Bondo" <> wrote:
    >
    > > Everything must take place on the client. The user opens
    > > the data.xml file and, after the XSLT processing, sees
    > > the XHTML.

    >
    > Poor choice. XHTML is not supported by MSIE. Transforming
    > on the client side should be avoided unless you know very
    > well what you're doing.
    >
    > > Since the full data set in data.xml can be quite large,
    > > I'd like to offer a familiar Prev|1|2|3|...|Next type of
    > > page navigation. How can this be done?

    >
    > If you want to transfer the entire data.xml to client and
    > transform it client-side, the question has nothing to do
    > with XML, since it boils down to implementing some
    > JavaScript-driven UI gimmick that would hide portions of
    > the resulting document. comp.lang.javascript is ===> that
    > way.
    >
    > > I've searched on the Internet, but found it remarkably
    > > quiet on the subject. Maybe I'm looking the wrong places.
    > > And perhaps it's not even an XSLT issue?

    >
    > Consider doing it the right way. Transform server-side,
    > serve HTML 4.01 Strict.
    >
    > --
    > Pavel Lepin


    Thanks for your prompt reply, Pavel. I understand your points -- I
    failed to provide adequate details about the situation:

    I have a native GUI application (.NET on the PC, Cocoa on the Mac)
    that manipulate some data (photos and their meta data). As a function
    in the application, the user must be able to locally generate web
    pages of the data for later upload to a webserver (a web photo
    gallery). The data set is exported to the XML file and then opened in
    an embedded web view in the application. The user can also choose a
    theme (a CSS file) that is referred to from within the XHTML output.
    The user is ultimately looking at CSS-styled XHTML page which is what
    I want.

    This already works as a proof of concept, but I need to provide some
    sort of navigation as mentioned in the original post.

    Since this is a photo gallery, I suspect the amount of XML data will
    perhaps be of the size of one full-size preview image, so bandwidth-
    wise I don't have a problem transferring the whole XML file. But
    perhaps there are other reasons not to.

    So my dream scenario was simply to generate the XML file, containing
    meta data and image paths, process that with an XSLT stylesheet and
    have the resulting XHTML nicely presented with the mentioned page
    navigation (index view: next page, previous page, jump to page, and
    for detail view: next photo, previous photo, index).

    As an alternative, I could generate a number of XHTML files, each
    containing the relevant photo and data presentation, (still using
    XSLT?), and upload these to the server.

    Suggestions are highly appreciated.

    Thanks in advance,
    Joachim
     
    Bondo, Apr 4, 2007
    #3
  4. Bondo

    Guest

    On Apr 4, 11:54 am, "Bondo" <> wrote:
    > On Apr 4, 10:05 am, wrote:
    > > On Apr 4, 10:34 am, "Bondo" <>
    > > wrote:
    > > > Since the full data set in data.xml can be quite
    > > > large, I'd like to offer a familiar
    > > > Prev|1|2|3|...|Next type of page navigation. How can
    > > > this be done?

    >
    > > If you want to transfer the entire data.xml to client
    > > and transform it client-side, the question has nothing
    > > to do with XML, since it boils down to implementing
    > > some JavaScript-driven UI gimmick that would hide
    > > portions of the resulting document.
    > > comp.lang.javascript is ===> that way.


    [...]

    > Since this is a photo gallery, I suspect the amount of
    > XML data will perhaps be of the size of one full-size
    > preview image, so bandwidth-wise I don't have a problem
    > transferring the whole XML file. But perhaps there are
    > other reasons not to.
    >
    > So my dream scenario was simply to generate the XML file,
    > containing meta data and image paths, process that with
    > an XSLT stylesheet and have the resulting XHTML nicely
    > presented with the mentioned page navigation (index view:
    > next page, previous page, jump to page, and for detail
    > view: next photo, previous photo, index).


    There are many possible solutions for the problem you've
    described, and there are simply too many imponderables to
    tell which one would be best (and I don't even mention the
    fact that decisions like that are always subjective to an
    extent, depending on your biases, preferences and
    practices).

    But as I said, in case you decide to publish the resulting
    gallery or whatever as a single XML document, transforming
    it client-side, the problem of paged interface will lie in
    the domain of client-side scripting, and will have nothing
    to do with XML, probably relying on HTML/CSS DOM
    manipulation to achieve the desired effect.

    > As an alternative, I could generate a number of XHTML
    > files, each containing the relevant photo and data
    > presentation, (still using XSLT?), and upload these to
    > the server.


    Replace XHTML with HTML, and that would be the solution I
    would be naturally gravitating towards, thanks to *my*
    biases and practices. YMMV.

    The simplest argument in favour of this approach is that if
    you're developing an application that exports some data, it
    is usually a good idea to do it in as interoperable way as
    possible, and in my experience, there's nothing that beats
    static HTML+CSS's readiness for deployment pretty much
    anywhere from litehttpd to PWS to Apache to IIS (as well as
    its accessibility to a wide UA base).

    --
    Pavel Lepin
     
    , Apr 4, 2007
    #4
  5. Bondo

    Bondo Guest

    On Apr 4, 2:19 pm, wrote:
    > Replace XHTML with HTML, and that would be the solution I
    > would be naturally gravitating towards, thanks to *my*
    > biases and practices. YMMV.
    >
    > The simplest argument in favour of this approach is that if
    > you're developing an application that exports some data, it
    > is usually a good idea to do it in as interoperable way as
    > possible, and in my experience, there's nothing that beats
    > static HTML+CSS's readiness for deployment pretty much
    > anywhere from litehttpd to PWS to Apache to IIS (as well as
    > its accessibility to a wide UA base).


    Thanks for taking the time to reply, I really appreciate that.

    I think going with a static(X)HTML+CSS files approach is the way
    forward. This leaves me with 2 general questions at this time:

    1) Can XSLT output to a file or in some other way so that I can grab
    the HTML data?
    2) If I have 80 photos, 8 on each page, do I generate an XML file 10
    times in order to generate the (X)HTML 10 files, or can XSLT do it in
    one go?

    Finally, I'm not sure why you shy away from XHTML (IE issues, you
    say). I've made several sites in XHTML 1.0 Strict, and IE and other
    major browsers display the pages just fine.

    Happy Easter,
    Joachim
     
    Bondo, Apr 4, 2007
    #5
  6. Bondo

    Guest

    On Apr 4, 7:05 pm, "Bondo" <> wrote:
    > On Apr 4, 2:19 pm, wrote:
    > > Replace XHTML with HTML, and that would be the solution
    > > I would be naturally gravitating towards, thanks to
    > > *my* biases and practices. YMMV.

    >
    > 1) Can XSLT output to a file or in some other way so that
    > I can grab the HTML data?


    Normally, you use your XSLT API to create a Processor
    instance, feed it a DOMDocument source tree and get a
    DOMDocument or DOMDocumentFragment tree as a result.
    Serializiation is usually up to you (that is, up to the DOM
    API you're using). Of course, that's just one of the
    possible scenarios, it is entirely possible to use a
    standalone XSLT processor, for example, either feeding it
    XML document files and getting transformation results as
    files as well, or using pipes for I/O.

    > 2) If I have 80 photos, 8 on each page, do I generate an
    > XML file 10 times in order to generate the (X)HTML 10
    > files, or can XSLT do it in one go?


    XSLT1 processors may only generate one result tree per
    transformation. There are ways to work around this (for
    example, if you're using a DOM+XSLT API, you may try a
    transformation that would return all the results glued
    together, then use DOM to yank the appropriate fragments
    out of it and serialize them separately).

    XSLT2 processors should support multiple result trees, but:

    - you'll have to either ask someone else about it or look
    it up yourself in the docs/specs;
    - the only readily available seemingly-fully-compliant
    XSLT2 processor that I'm aware of is Saxon8, and I'm not
    certain how hard it would be to use it as a
    transformation engine under .NET framework. Again, ask
    someone else or, well, GIYF.

    > Finally, I'm not sure why you shy away from XHTML (IE
    > issues, you say). I've made several sites in XHTML 1.0
    > Strict, and IE and other major browsers display the pages
    > just fine.


    Again, GIYF. In short, XHTML is unsupported by MSIE. To
    make it work you have to serve it as invalid HTML with
    text/html MIME type. Being invalid it triggers quirks mode.
    Once you're in quirks mode, you're in what C++ crowd calls
    Undefined Behavior Land. You don't want to be in UBL, just
    trust me on this one.

    I don't even mention the fact that serving XHTML as
    text/html places certain constraints on its serialization,
    which mean you cannot process it as pure XML anymore.

    I don't even mention the fact that to get any use out of
    it, you have to serve it as application/xhtml+xml to
    Gecko-baseds, which requires a small bit of Apache mojo to
    pull of and strikes me as slightly silly.

    All in all, using XHTML for public websites is ugly,
    inelegant, useless and prone to causing Developer Brain
    Explosion Syndrome at worst possible moments. The only
    place where XHTML has its uses ATM is as an internal
    representation of something you intend to actually serve
    as HTML. There are advantages in it being XML, and
    transforming XHTML 1.0 Strict to HTML 4.01 Strict is pretty
    much effortless, the main difference between the two being
    that one is an XML application, and the other is an SGML
    application.

    --
    Pavel Lepin
     
    , Apr 5, 2007
    #6
  7. > All in all, using XHTML for public websites is ugly,

    Hmmm.

    There's really little or no excuse for a browser not accepting XHTML
    these days. I grant that for business-critical websites you may need to
    code down to the limitations of the customer's preferred browser... but
    there comes a point at which we, as customers ourselves, need to start
    pressuring the vendors to provide proper support for modern standards.

    Remember, W3C's intent was that XHTML replaces the old SGML-based HTML.

    Nothing's wrong with XHTML. Demand working browsers.


    Meanwhile, even if you have to serve old-fashioned HTML, there's
    something to be said for using XHTML on the server end and converting it
    to HTML only at final serialization onto the wire.


    --
    () ASCII Ribbon Campaign | Joe Kesselman
    /\ Stamp out HTML e-mail! | System architexture and kinetic poetry
     
    Joe Kesselman, Apr 5, 2007
    #7
  8. Bondo

    Guest

    On Apr 5, 3:19 pm, Joe Kesselman
    <> wrote:
    > > All in all, using XHTML for public websites is ugly,

    >
    > There's really little or no excuse for a browser not
    > accepting XHTML these days.


    Oh, when was the last time Microsoft needed excuses for
    anything? Excuses are for small businesses anyway.
    Corporations use visions instead.

    > I grant that for business-critical websites you may need
    > to code down to the limitations of the customer's
    > preferred browser...


    If we're talking about public websites, customer's
    preferred browser is unknown. At best we know the content
    types the UA in question finds acceptable (and then some of
    them lie shamelessly; okay, scratch that, I've no
    supporting facts on this count, it's just that I find the
    entire situation extremely annoying).

    > but there comes a point at which we, as customers
    > ourselves, need to start pressuring the vendors to
    > provide proper support for modern standards.


    Right. We might as well start kicking the dead whales down
    the beach.

    Actually, since we started talking about standards, Gecko
    engine, for one, has quite a few ugly blotches all its own
    on its face. I actually set that cute Foxy saying 'Please
    don't hurt the web. Use open web standards' as my
    wallpaper, but the web developers still can't push the
    Gecko Dev Team into fixing that ugly, standards-incompliant
    wart re 4096 octets max size on text nodes. Three years and
    counting.

    I'm pretty certain KHTML et al have more than enough
    skeletons buried in their sources as well.

    > Remember, W3C's intent was that XHTML replaces the old
    > SGML-based HTML.


    I agree fnord completely. In fact, I was thoroughly
    disgusted when W3C chartered HTML 5 WG. Now, I don't know
    about pushing Microsoft, but maybe we *could* push W3C into
    ending this nonsense once and for all?

    > Meanwhile, even if you have to serve old-fashioned HTML,
    > there's something to be said for using XHTML on the
    > server end and converting it to HTML only at final
    > serialization onto the wire.


    To be fair, there's nothing wrong with using HTML 4.01
    Strict--assuming you're using it properly. It would be
    great if we could switch to serving XHTML 1.0 Strict and
    get away with it, but at the moment--we can't.

    And if we're using HTML anyway, isn't it a bit more sane
    to stick to *one* markup language instead of catering to
    every UA's idiosyncrasies? HTML4.01, for all its faults,
    is a working, workable standard. XHTML1 isn't. A shame,
    really, but them's the breaks.

    --
    Pavel Lepin
     
    , Apr 5, 2007
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roger Varley
    Replies:
    20
    Views:
    933
    jan V
    Aug 14, 2005
  2. Replies:
    2
    Views:
    552
  3. Replies:
    7
    Views:
    959
  4. Lord0
    Replies:
    3
    Views:
    552
    George Bina
    Nov 23, 2006
  5. Replies:
    7
    Views:
    301
    A. Sinan Unur
    Feb 14, 2006
Loading...

Share This Page