> Now that we can give more thought to it, it is clearly visible that a > markup-rich solution is better, which shows us the structure of the > list. For see also lists, the role would enable DSSSL and XSLT sheets to > find out how the list items need to be separated and how the last item > needs to be printed. It might also happen that simplelist already works > this way (I have not tried it). > > Why I have not shouted in to oppose the continued use of &listeandand; > is that the use of this entity makes these kind of lists instantly > findable in the source, so we can convert to a semantically better > markup later if need be. However since there are already so much to do > around the files, the changing of the see also lists might not be that > big of a task anyway.
Do you feel this should holdup the new doc style? As far as I see there are three remaining items: (a) See Also format Everyone agrees that clean markup is better than manually entering commas and and's (or entities) but how or when will this be implemented? It would be nice to have this done before moving to the new style, I can't tell if this is what you mean. Ref: http://marc.theaimsgroup.com/?l=phpdoc&m=109319660307520 (b) Parameter listing information The parameter listing lives within a variable list, and information such as reference, type, and optional all live within the methodsynopsis. The idea is to have the parser extract the information from methodsynopsis and insert said information into the variable listing. The structure (afaict) is already in place so this may not be a holdup. I don't think we need to worry about dsssl/xslt for this, only livedocs, and worry about that later. Just so we agree that the current new doc format will do. Ref: http://marc.theaimsgroup.com/?l=phpdoc&m=109278378703942 (c) Constants on own page Not a big deal, everyone agreed on this. We could get away with what we have now and it'll all work fine in both livedocs and dsssl but...I guess it comes down to who's our dsssl guru, and where do they live :) Regards, Philip
