Re: Module submission TEILite
On Friday 21 June 2002 10:44, Perl Authors Upload Server wrote: > This library package is not the most easiest to classify. The Text > Encoding Initiative is a group that has defined a schema originally > SGML based for the generic mark-up of documents. It is slowly > starting to be adopted by libraries and electronic document centers > (even more so now that an XML version of the specification has been > produced). The TEI specification is quite large as it is designed to > be able to markup from everything to songs to poetry to technical > papers to novels. Since the full TEI specification is quite large a > 'Lite' version was made that is a subset that allows a person to > markup over 90% of the type of documents one would encounter. The > goal of this library is to implement the TEILite specification that > is based on XML as this seems to be the most common path that > libraries and such are using. It might be better to make a generic > TEI root node and put this under TEI::TEILite or possibly > XML::Schema::TEILite. I think I would like to stay away from the > XML::Schema::TEILite as the XML::Schema might provide the wrong > impression (as in modules for building XML schema models). Applications of XML often tend to go directly under the XML:: namespace. I'm ready to be proven wrong but I don't think TEI needs a top level namespace of its own. XML::Schema is probably a bad choice too, as people would indeed think that it is an implementation of W3C XML Schema (and if they have any sense, run away fast ;). Given that it is a DOM wrapper, why not simply XML::TEILite? -- Robin Berjon <[EMAIL PROTECTED]> -- for hire: http://robin.berjon.com/ A computer lets you make more mistakes faster than any other invention, with the possible exceptions of handguns and Tequila.
Re: Module submission TEILite
On Saturday 06 July 2002 22:17, D. Hageman wrote: > On Sat, 6 Jul 2002, Robin Berjon wrote: > > Given that it is a DOM wrapper, why not simply XML::TEILite? > > I guess the only reason why I didn't go with XML::TEILite is that I > thought as TEI becomes more established that more people would be > interested in adding additional tools. I guess one can't really predict > the future and if later this prediction becomes true and people do such a > thing and more 'group'ing namespace can be considered then. I am okay > with the namespace XML::TEILite. As Tim pointed out recently, some top level namespaces such as Apache:: or XML:: are so generic that three-level names make sense. Thus, people wishing to develop addition TEI tools would use XML::TEILite as their root namespace. The same discussion occurred with the same conclusion when the perl-xml list was debating whether to use XML::SAX::* or have a SAX:: top level namespace. -- Robin Berjon <[EMAIL PROTECTED]> -- for hire: http://robin.berjon.com/ "I will not teach Plato. I shall teach nothing but the truth." -- Rudolf Carnap
Re: Module submission TEILite
On Monday 08 July 2002 12:48, Tim Bunce wrote:
> > On Sat, 6 Jul 2002, Robin Berjon wrote:
> > > Applications of XML often tend to go directly under the XML::
> > > namespace.
>
> Be careful here... The XML namespace should be reserved for modules
> where manipulating XML is the primary purpose. *Applications of XML*
> to a specific problem (like Job Control :) should *not* go into the
> XML namespace. Of course, that distinction can be a fine one sometimes.
What I meant (unfortunately not very clearly) but "applications" are
vocabularies used as such. That is, things like SVG, XHTML, XSLT, etc where
the fact that they are XML is an integral part of the technology. Obviously,
something that just happens to use XML doesn't fit there :)
> I notice the text above says "The TEI specification is quite large"
> (implying possibly more modules over time) and "the TEILite
> specification that is based on XML" (implying there are non-XML
> aspects to it).
I admit to having judged this almost only on this specific module which is a
DOM wrapper/extension in a way similar to the way in which, say, the SVG DOM,
wraps/extends the Core DOM.
> Given those points, and that the Text Encoding Initiative is a "big
> thing" ("adopted by libraries and electronic document centers")
> I'd go with a new top-level namespace: TEI.
Part of what motivated my answer was that "TEILite" didn't seem appropriate
as it is itself a subsection of TEI. What would you think of TEI::Lite then?
--
Robin Berjon <[EMAIL PROTECTED]> -- for hire: http://robin.berjon.com/
Learn from your parents mistakes - use birth control.
Re: Module submission Apache::SAX::ConsumerObject
On Tuesday 30 July 2002 17:56, Perl Authors Upload Server wrote: > I am not at all wed to the suggested package name, but I couldn't > dream up anything better. > > The package simply provides a valid consumer object to allow > XML::SAX::Writer to print to STDOUT inside a mod_perl handler. > > By default, if no "output" widget is passed to XML::SAX::Writer, it > will print to STDOUT. This doesn't seem to work in a mod_perl > context, which means you have to create a scalar and fill it up with > stuff before printing it at the browser. > > my $output = Apache::SAX::ConsumerObject->new($r); my $writer = > XML::SAX::Writer->new(Output=>$output); There was talk at OSCon about XML::SAX::Writer consumer extensions. I don't know if any of those will happen, but the general idea was that they would go under the XML::SAX::Writer namespace. In this case that'd make it something along the lines of XML::SAX::Writer::ApacheConsumer. I'm uncertain of whether that would be a good idea or not and am merely suggesting it as a possible alternative, for discussion. One downside is that it's a long name, one upside is that it's more descriptive (imho) of what it does than Apache::SAX::ConsumerObject. Another option might be Apache::SAX::WriterConsumer. I think that's more explicit as it points out the link to XSW and doesn't include the "Object" part which is more of an implementation detail. Finally, it may be possible to borgify that straight into XSW. If provided a $r object it could use that as its consumer (more dwimmery there, and imho generic enough to be worth including). If you think that's a good idea, I'll include it with the next release. > Matt Sergeant has already written a similar package for AxPoint, > but it would nice to have a simple bare bones consumer that does not > require installing all the stuff used by AxPoint. There also was talk of making the Consumer-selection code more open to the outside world so that packages like AxPoint would not need to reimplement it. If you have any suggestion in that area, please send them to me (in personal mail as this is not the place) and I'll incorporate them into what is already there. -- Robin Berjon <[EMAIL PROTECTED]> For every complex problem, there is a solution that is simple, neat and wrong. -- H.L. Mencken(1880-1956)
Re: Module submission Petal
On Tuesday 30 July 2002 18:37, Jean-Michel Hiver wrote: > On Tue 30-Jul-2002 at 05:10:57PM +0100, Tim Bunce wrote: > > On Tue, Jul 30, 2002 at 06:01:36PM +0300, Jarkko Hietaniemi wrote: > > > I think Template::Petal will work just fine. XML::Template I do > > > not like, "XML::" is quickly becoming is as information-free as > > > "Sys::"" > > > > Agreed. > > Well, except that it's really what it's meant to be doing, processing > XML files... RSS, SVG, XHTML, VoiceXML, you name it. If it were to be under XML::, then it would probably have to be something along the lines of XML::Template::Petal because XML::Template is too generic, and there already are other XML templating systems (a bunch of XSLT implementations, XPathScript, etc...). What your module is at heart is a templating system. I know that it works using attributes which would tend to link it to XML and HTML but you don't know where it might go in the future. There are other ways to glean attributes than the way it's done in XML and HTML. Perhaps someone will add functionality to somehow read in Pyx or YAML, or in fact anything that represents data structures so long as there's a way to look elsewhere in the tree and identify stuff as attributes. I'm pretty sure that the Mason folk would have been happier chosing Template::Mason than HTML::Mason, simply because what they do is templating much more than HTML, and even though 99% of the time Mason templates deal with HTML. I cannot speak for them, but imho if you ask their opinion the odds are they'll shout "Template::Petal" in unisson ;-) > If everyone agrees that this module is primarily a templating system > rather than an XML tool, fine. I'll be glad to remove the HTML > functionality and make it process stricly XML files if that makes more > sense. Removing the HTML bits would not be a prerequisite to going into into the XML namespace so long as it is primarily an XML tool and doesn't warp XML (eg XML::LibXML reads HTML as well). I know that the boundaries of what XML is are now very much blurred thanks to SAX being able to read and write anything, only pretending that it's XML in the middle but I still do think that Petal is more orientated towards templating than towards XML. In other words, it makes sense without the XML bits but doesn't do anything without the templating bits. As such, I think that Template::Petal just works great. -- Robin Berjon <[EMAIL PROTECTED]> Forty two.
Re: RFC: Acme::No
On Thursday 08 August 2002 17:05, Geoffrey Young wrote: >I was thinking about releasing Acme::No to CPAN but wanted to make > sure that it follows the spirit of the Acme:: namespace properly. I am not a great specialist of Acme::* modules, but I /think/ it boils down to whether you intend to whether you think your module ought to be used seriously or not ;) If you do, I then think no one will use it if it's in Acme. If that's the case, then maybe you'd be happier in the ex::* namespace, indicating an experimental pragma. Then again that may give the impression that it's blessed as being under review by p5p which unless you push it further there (and it may be a good idea as "no LWP 6.0.0" complaining that it only has version 5.65 is a bit counter-intuitive -- or at least a syntactical hole) is not the case iirc. Or perhaps under Perl::* given that it modifies Perl semantics for a keyword, eg Perl::NotVersion or something similar. I'm not recommending any of these specifically, just trying to suggest alternatives to Acme::* if your module is "serious" (which to me it seems to be). -- Robin Berjon <[EMAIL PROTECTED]> As a computer, I find your faith in technology amusing.
Re: New module XML::NamespaceSupport
Hi Pause Team! Thanks for adding this module, it'll make a few things easier later. I'd like to reiterate my offer for help in assigning/accepting module data to the list. I understand that it's slow because people are busy, and that not anyone can be trusted to help (so I understand if you'd turn help down). It's just that if there's a way in which I can help, I'd love to. I certainly owe it to the community ;) Take care, -- Robin Berjon <[EMAIL PROTECTED]> -- I'm not a complete idiot - some parts are missing!
