| You seem to suggest two things in your mail:
| - the scripts on phpdoc.info were not supposed to be publicly announced
| - the scripts on phpdoc.info are not supposed to be open source
If you append "yet" to each of these bullets, it becomes truth.
Good.
Seems the dust is settling, and efforts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allow me to apologize for sounding much more harsh than intended.
I don't have a lot of time today, so this will be brief, but:
- - I didn't intend to hide any of the tools. _my_ few tools are not ready
to be committed, and I don't even know if docbot s
Hi Sean,
Let me start to react from the end of your mail, where you have written:
| Note: I've also written a factoid bot that sits on #phpdoc that wasn't
| linked above, it's tied into [PHP-DOC] and alerts us to commits, as
| well. I hope I won't be shamed for that, too.
This seems to suggest that
As far as the server situation, I am way out of the loop on that but
AFAICT one group started and for various reasons failed so it's time
to move on to the next. In other words, use Jacques server. This is
the same for a PHP mirror, once it's moved to another server that's
it.
+1 ..
I'm really
Not bad as is! ;)
Well, since it is not a note semantically, I don't think we would
need to have a note. Otherwise using the para variant, all the
versions seem to look quite acceptable. Looking at these real list
presentations, I wonder if it better useabilitywise, if we put the
list items on
Not bad as is! ;)
Well, since it is not a note semantically, I don't think we would need
to have a note. Otherwise using the para variant, all the versions seem
to look quite acceptable. Looking at these real list presentations, I
wonder if it better useabilitywise, if we put the list items on a
> > Not bad as is! ;)
>
> Well, since it is not a note semantically, I don't think we would need
> to have a note. Otherwise using the para variant, all the versions seem
> to look quite acceptable. Looking at these real list presentations, I
> wonder if it better useabilitywise, if we put the
As far as the phpdoc.info stuff goes, this all came about through the
active #phpdoc channel on freenode. Many of us work together on various
tasks so various people created tools. I see it as a testing ground
for docweb but the docweb situation is unknown right now so until it's
figured out we
(please don't take any of my paragraph replies as a whole)
Gabor Hojtsy wrote:
It is somewhat positive to see so many people doing things, but it is
quite satiric to see that there is no common way, and everyone comes up
with his own solutions.
I can't speak for the others, but I think I've clea
Here's something to get started with:
Patch:
* http://boogle.com/tmp/simplelist-patch.txt
Livedocs output:
* http://livedocs.phpdoc.info/index.php?l=en&q=function.exif-read-data
DSSSL output:
* http://boogle.com/tmp/simplelist-dsssl.html
XSLT output:
* http://boogle.com/tmp/
> > (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.
>
Could someone please collect all the sites already set up with docweb
stuff, wikis, pepr copies, livedocs and stuff, so we don't continue with
more sites getting up and going down? It would be nice to summarize the
situationon [EMAIL PROTECTED] I must admit I am getting to loose the
picture (wh
(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 varia
> > There are a few, the exif docs already use it. And they
> > also live within the unofficial official phpdoc wiki:
> >
> > http://wiki.phpdoc.info/DocSkel/FunctionskeletonDotXml/
>
> Could someone please collect all the sites already set up with docweb
> stuff, wikis, pepr copies, livedo
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
There are a few, the exif docs already use it. And they
also live within the unofficial official phpdoc wiki:
http://wiki.phpdoc.info/DocSkel/FunctionskeletonDotXml/
Could someone please collect all the sites already set up with docweb
stuff, wikis, pepr copies, livedocs and stuff, so we don'
> > (a) See Also format
>
>
>
> print
> echo
>
>
>
> That looks fine to me!
Now all that's needed is for it to work :)
> > (b) Parameter listing information
>
> Really good idea, but the structure is not explained clearly.
>
> Care to write an example?
There are a few,
> (a) See Also format
print
echo
That looks fine to me!
> (b) Parameter listing information
Really good idea, but the structure is not explained clearly.
Care to write an example?
> 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
> ne
Hi,
This has been discussed many times with many dead ends. Here
are some see also threads:
http://marc.theaimsgroup.com/?l=phpdoc&m=100894842011360
http://marc.theaimsgroup.com/?l=phpdoc&m=101051061316162
http://marc.theaimsgroup.com/?l=phpdoc&m=105601918607181
One structure that was propos
> I agree with everything except the seealso.
>
> Let's formalise it and let XSL do the hard work.
>
> We can make a simplelist, or find some relevant docbook tag, sticking the
> entity in is a bit dirty.
This has been discussed many times with many dead ends. Here
are some see also threads:
I agree with everything except the seealso.
Let's formalise it and let XSL do the hard work.
We can make a simplelist, or find some relevant docbook tag, sticking the
entity in is a bit dirty.
A few concerns:
a) What sort of changes should be included when moving to thenew
doc style?
* Should we include Whitespace changes?
I'd say yes. Let's clean everything at once, we don't want to add more
work for the translators.
All agreed!
* No content changes! (Don't follow my exif exam
23 matches
Mail list logo
