This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Docbook xsl stylesheets and accessibilityrequirements?


Adam DiCarlo wrote:

> Tobias Reif <tobiasreif@pinkjuice.com> writes:
>
>>I did not say that the linked XSLTs are patches for the
>>NW-DBK2(X)HTML-XSLTs, or that the code's purpose is to be integrated
>>into them.
>>
> I know.

Then I'm confused why you wrote

"It's easier to integrate/patch in when you do it as a customization to
docbook-xsl rather than starting from scratch."

The portions of my post you referred to had nothing to do with the NW-DBK2(X)HTML-XSLTs.

>>This lis is titled
>> DOCBOOK-APPS
>>which seems to imply that it about DocBook tools *in general*.
>>So it can not be assumed that everything is somehow directly related
>>to Norm's software.
>>
> Sure, of course.

Great that we agree on this.

>>You misunderstood me in fundamental ways.
>>
> No, not really.

I still think so :)

> I never meant to say what you did is wrong.

I know. But somehow you seemed to think that my code was indended to be incorporated into Norm's XSLTs, or that I should bring them in a form which makes this easier.

> I only
> stated it doesn't move docbook-xsl xhtml output towards strict
> compliance.

Yes; you wrote

"[URL]
This probably isn't very helpful to the DocBook-XSL developers."

Lots of things which are not related to the NW-DBK2(X)HTML-XSLTs are also not helpful to their developers; I would think that this is natural, and obvious.

>>I spent many weeks over many months trying to customize the
>>NW-DBK2XHTML-XSLTs to meet my requirements (including giving lots of
>>feedback, offlist), then at one point found that the only way to
>>really get the kind of output I need, I must write my own XSLTs.
>>
> Perhaps you could summarize the way docbook-xsl did *not* work for
> your needs.

I'm sorry, but I won't.

1. I'd have to harvest the content of many many emails I sent offlist, which would take a lot of time. Many are not in my sent box anymore.

The feedback already reached it's best and most appropriate destination.

2. It would not help you in any way. You have your own set of requirements, and you have to explore on your own if Norm's package(s) meet(s) them (plus your customizations).

As for general requirements such as validity: They clearly state and explain themselves. There are many different "correct" ways to achieve stuff like accessibility etc; It doesn't help if I recap what my idea is of implementing these aspects.

> That might be the basis of a critique of how docbook-xsl
> xhtml output is working.

The NW-DBK2(X)HTML-XSLT package already generates XHTML.

> Personally I think it's the responsibility of the developers (of which
> I'm not really one, since I'm only working on DSSSL now) to be able to
> produce strict output conforming exactly to the spec (as an option or
> by default).

This is very hard to do, and can never be promised. DocBook is very large, and valid instances vary *greatly*.

> This is on the basis of the old adage, be flexible in
> what you accept and strict in what you produce.

Yes, I agree that validity is of major importance. (in both in- and output IMHO)

> I'm not saying it's
> your duty to help with this

OK.

> -- but it might help if you would.

I did help a lot already (invisible to you), and I'm sorry to tell you that I won't help any further. Over many months, I sent many many emails listing sample in- and output, validator messages, suggestions about accessibility, usability, and other aspects, and lots of other feedback.

>>I started from scratch, and I'm very happy with the XHTML I get.
>>
>>I think that makes a lot of sense, and I'm also not the only one
>>writing his own DocBook2[foo] XSLTs. Others have unmet requirements as
>>well, but that does not say *anything* about Norm's XSLTs. No single
>>software package can ever meet all possible requirements or
>>preferences.
>>
> That's true. I have a real fear of reinventing wheels, however.

Don't fear; its my time I'm investing :)
And I'm making all my efforts available online.

And there is no wheel being reinvented:
As I said, no software package can meet all the requirement sets of all developers and projects.
There's more than one type of car, more than one browser, more than one XSLT processor; no wheels reinvented.

I hope that you'll be able to fully accept the fact that there aree more than one set of DocBook2XHTML XSLTs.

> It's just that you've done all this work and you have valuable
> experiences on producing strict XHTML from docbook,

I don't really; see below.

> and I think we
> could transfer some of that knowledge to the XSL stylesheets.

I assume with "the XSL stylesheets" you mean Norm's?

Check
http://www.pinkjuice.com/howto/vimxml/about.xml#sources

Validity is *very* hard to achieve for arbitary valid DocBook input.
No XSLT author could ever promise that all output generated by his XSLTs will be valid, AFAICS.

http://www.pinkjuice.com/howto/vimxml/xslt/tinydbk2xhtml/
generates valid output for
http://www.pinkjuice.com/howto/vimxml/docbook/ .
*No other input* was ever tested.

http://www.pinkjuice.com/doxy/
will be a rewrite. I am very excited see how I can deal with a larger subset of DocBook; it'll be an adventure :)

BTW, there are other DocBook2XHTML XSLTs online if you want to see what others are doing; ask Google :)

Tobi

--
http://www.pinkjuice.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]