Ferdinand Soethe wrote:
I've responded there. Can I ask you also read the archives about why we
insist on going through an internal format.
I actually have been following these discussion in the past and I
still agree with you
- as long as we are talking about publishing content in
standard Forrest output channels
Well that is what Forrest does, so no argument there.
(I snipped the brakcet about slidy as there is a whole other thread
about that now and will address it there)
- as long as we talk about XHTML2 as our meta format because xdocs is
way to limited to transport all the information that specialized
grammars provide.
We have *always* talked of this. Note that a long time ago we agreed
that anything in the XHTML2 subset we have agreed on can be put in to
document 2.0 as and when requried without the need for a vote.
So again, no argument for me.
This comes up every six
months or so.
I distinctly remember a very similar discussion with Sean
Wellar (or Whellar, or some similar spelling, sorry Sean), this was in
relation to bypassing XDoc for docbook inputs.
It's Sean Wheller actually. And now that I see his name again I
recognize him as the maker of my favorite XML-Editor (Oxygen) if it is
the same person.
Anyway. It seems like you have two to argue about this now :-)
Actually, what you argue in the other thread is completely different
from what others (including Sean) have argued in the passed. What has
become clear in the other thread is that you are talking about bypassing
the internal format when you don't want to use Forrest's skinning. That
is a completely different issue and I will address it in your thread
"Bypass plugins".
That said, to make this work you'd have to start by
- allowing div and span elements in the doc13 grammar (which would be good for
a number
of other applications as well)
div and span are both in our XHTML2 subset so not problem there.
Similarly views use them extensively.
Well I'm talking about div and span being used in Xdocs. Which atm is
not legal in it's grammar.
It is in our agreed XHTML2 subset, tehrefore you can add it to Document
v2.0 if you need it.
- continue by preventing our current pipelines from 'loosing' or
overwriting class and id attributes from a number of elements (some
of them - such as body - involving rather complex changes).
We have already established that is a bug, so no problem there.
Except that I consider it a waste of resources to do this for
soon-to-be-phased-out xdocs.
So spend the respources on getting XHTML2 implemented then ;-)
Some of which to looked like a nightmare in terms of doing it,
documenting it and preserving backward compatibility etc. And
Especially since a clean implementation of XHTML2 would remove most of
these obstacles anyway.
Another push for XHMTL2 then, good.
OK, so what is the solution for that plugin now?
Do you mean the XHTML2 plugin? If so the answer is that the views folk
felt the approach was wrong. We are now waiting for views 2 before we
can proceed.
Ross
