Re: [ubl] UBL 1.0 SBS permanent absolute web location (urls)

["Stephen Green" <stephengreenubl@gmail.com>]

Sorry for yet another email about this but I've found that there is no
similar problem with the UBL 2.0 public review package so I'm guessing
there must be something in my XHTML causing this :-(

Maybe if I take the UBL index.html and rewrite the SBS index that
will solve, but ideally is there a way to test this before it becomes 'written
in stone' as it were (pending TC ballot, it would be a committee spec).

I guess we'll need to revisit the UBL 1.0 SBS editing before a ballot
in case a lot has to be changed.

Thanks and apologies,

Stephen Green

On 01/03/06, Stephen Green <stephengreenubl@gmail.com> wrote:
> I just realised of course that Kavi uses PHP, about which I know little.
> Could there be an issue with PHP and XHTML or does it just depend
> on how PHP is set up or on the CMS which serves it?
>
> On 01/03/06, Stephen Green <stephengreenubl@gmail.com> wrote:
> > Robin, Mary,
> >
> > Would it be feasible, for the committee specification version
> > of the package, to do something such as provide an index.html
> > file which does little more than redirect or provide a link to the
> > problematic, previous index file, having renamed the latter to
> > something else such as, in this case, cs-UBL-1.0-SBS-1.0.html?
> >
> > Or could the problem be solved with something clever in Kavi
> > to the same effect, say? Is the content-type set to something
> > unusual? Can it be changed?
> >
> > It's just that I'm convinced the problem isn't so much with the
> > actual XHTML file so much as the way it is served to the browser.
> > When the same page is viewed locally in a browser there isn't
> > a problem. Along the lines of Bryan's suggestion, I think it
> > might be something like a mime or content type given by Kavi to
> > the top level file  - just as Java servlets allow specification of
> > content-type when they serve a page (I think, though I admit that
> > servlets are not my specialism).
> >
> > Thanks
> >
> > Stephen Green
> >
>