[postgis-devel] Do you think we should put a note about 2D and3Don each function?

[Obe, Regina]

Don't we need our own dtd extension for that?  Not sure.

You are one ahead of me Kevin - haven't really thought that far.  

I have the first draft of the xsl that pulls the comments from the
reference_new.sql and transforms to a .sql file.

Attached is it and what the sql output it generates looks like.  I
tested it on my 1.3.3 install (my 1.3.4 install is on my VM which for
some reason I can't connect to at the moment so I couldn't test on
that).

I had to remark out some function comments that didn't exist on my 1.3.3
install to get it to work, but seems to run with what we have so far in
docs.  I was trying just against my XSLT IDE parser - haven't tried
using the XSLTPROC since that's on my VM.  Don't see why it wouldn't
work.  Can one of you test and see if it works with the build and also
decide where we should put it.

Its not the most elegant of xsl, but its the best I can do with what I
know so far.  I probably should have split out some things in
xsl:template constructs, but couldn't get it to work.

Thanks,
Regina

  

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Kevin Neufeld
Sent: Friday, September 19, 2008 1:41 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Do you think we should put a note about 2D
and3Don each function?

I agree.  Having our own extra xsl would cleanup the sqlmm and ogc 
compliant tagging.  Give 'er a try.

How would this work with the different conversions we do (html, chunked 
html, and pdf all use different docbook stylesheets)?  Would we have to 
create three different xsl wrappers for html/docbook.xsl, 
html/chunk.xsl, and fo/docbook.xsl?
-- Kevin


Mark Cave-Ayland wrote:
> Obe, Regina wrote:
>> Is there an easy way to define a new tag or something for this.  I
was
>> thinking if we had a separate tag for it, it would be easier to pull
out
>> those functions that have that tag later.
>>
>> I guess we have similar issues with MM.  Anyrate we can still do it
if
>> we stick to the same terminology, but I figured it would be less
prone
>> to error if we had a tag.
>>
>> I am feeling a bit more confident about my XSLT abilities now that I
>> have a couple of unrelated projects that involved me having to write
xsl
>> files to transform the data into another format.  I was hoping to
tackle
>> generating the function alter comments statements in the next week or
so
>> trying to stick with just using a custom .xsl file for minimum
increase
>> in dependencies.
>>
>> Which brings me to the topic of if we create a custom xsl file for
this,
>> where should we put this in the source tree or is this direction
>> completely wrong?
>>
>> Thanks,
>> Regina
> 
> I'd say post a proof-of-concept to the list. As long as the paths
within 
> the docbook source are all relative, I see no reason why we can't 
> include an extra .xsl file if required.
> 
> 
> ATB,
> 
> Mark.
> 
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel


-----------------------------------------
The substance of this message, including any attachments, may be
confidential, legally privileged and/or exempt from disclosure
pursuant to Massachusetts law. It is intended
solely for the addressee. If you received this in error, please
contact the sender and delete the material from any computer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postgis_comments.sql
Type: application/octet-stream
Size: 15575 bytes
Desc: postgis_comments.sql
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080919/141f8a4a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: postgis_comments.sql.xsl
Type: application/octet-stream
Size: 2300 bytes
Desc: postgis_comments.sql.xsl
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20080919/141f8a4a/attachment-0001.obj>