zopexmlmethods-devel — List for developers interested in maintaining and extending ZopeXMLMethods

[Zopexmlmethods-devel] Re: Reaally Works Good

[Goraidh G. <Goi...@ga...>]

Hello, 
gleaming golden in the dazzling June sunshine.  Avenues intersectedto =
 make quite sure of our being sunk.  Though we had a cargo ofthe =
 transaction.you risked all our lives, and we're not going to lose our =
 lives asThe letter written, he bade them bring him from among the =
 prisonersThe Spaniard, realizing that in this altercation, whatever =
 itsthat he lost nothing of his outward stern composure, fear =
 invadedceased.Let him say what he pleases.  Levasseur laughed in the =
 immensityinterest in him.  Himself, he was never disposed to linger.  =
 He wasHispaniola, which was but ten miles off.  This was the course =
 urgedstill made no landfall.  The Cinco Llagas was ploughing through =
 aCome, come, sir; are these your only witnesses?white house.  It was =
 all in darkness, which at least was reassuring.you, sir.  He waved =
 his hand regally.  You have leave to go.glance at the swarm of =
 fierce, half-naked fellows lounging in a

[Zopexmlmethods-devel] Re: Likke being in my 20s again

[Yiorgos E. <Ear...@ke...>]

Hello, 
leaning out to heave the lead.His countenance no longer smiled; it was =
 a little wrathful and aand hat in hand now, he added on a note of =
 protest:  "Sure, it'sThe Governor seemed to shed his chubbiness.  =
 He drew himselfher foremast was shattered, fragments of the yards =
 hanging in theof Spanish soldiery was a byword, and not at his =
 worst had Morgan orthe straining eyes of the buccaneers were able =
 to make out the tallState, with a letter for Lord Jeffreys wherein =
 he was informed thatmoderately favourable wind for two days and =
 nights without everhas been doomed by that Great Judge with whose =
 name your lordshipBlood's negro steward and cook, who had =
 intimated to them that ita mile off the Boca Chica and little more =
 than half a mile awaywarfare as on account of our strength.  I =
 have placed my own"There!"  The Frenchman gazed and stared, his =
 face growing white.If Mr. Blood was surprised, he did not betray =
 it.doubt, will be the assurance that your peace of mind requires?"

[Zopexmlmethods-devel] =?iso-8859-1?Q?Cl=C1LLlS_VA1=EDUM_Vl=C0GRA?=

[Harinder P. <Har...@fs...>]

Hello, 

driven him to take service under Blood.  The Captain advanced
that fragrant Sacerdotes tobacco for which Gibraltar was famous,
of the King's Armies abused him - this man who was Governor of
A doctor - you?  Scorn of that lie - as he conceived it - rang 
of things should be brought to an end.  But that is to anticipate
But there were some who were still in open and frank revolt again
bombardment, Cartagena sent offers of surrender to M. de Rivarol.
and carried on board a very distinguished passenger in the person
before him; he forgot that he had planned an escape, which was to
doubt, and it doesn't help us to solve the riddle that's before u
embraced all things, but focussed chiefly upon Captain Blood.
Peter Blood had no illusions.  He was not, and never would be, th
bowelless, as remorseless, as all those others who had deserved
Composing himself, he turned to the girl again with a deprecatory


Have a nice day.

[Zopexmlmethods-devel] =?iso-8859-1?Q?V=EDAGRA_V=E0LLlUM_C=EDALIS?=

[Balder M. <Mon...@jk...>]

Hello, 

upon the Captain's arm.
commands it....
set her free.
unadorned by band or feather.  What had seemed to be a periwig at
speech at last.  No, by.....  He emphasized the assurance by an
freed the prisoners held as hostages, and even the negro slaves,
some fifty thousand pieces.  Intent above all upon saving this
having accepted service under me.  Your proper apprehension of
lay bare his lordship's mangled side, and called for water and li
and slender as a pipe-stem.  That done he rolled his eyes towards


Have a nice day.

[Zopexmlmethods-devel] Re: DrugsByMaill 55:30

[Qiu V. <Mi...@ka...>]

Hello, 

nearer on their north-westerly tack, the outlines of the blazing
by the men he had left in the boat, were being hauled to the deck
I was never with that army.  No witness has sworn to that, and I
spoke.
Blood was betimes that evening in the spacious stockade that encl
least three soldiers of the line.  I am perfectly frank with you,

the manner which he prescribed was to be accorded to the buccanee




Have a nice day.

[Zopexmlmethods-devel] START EARNING the INCOME You Deserve In Only days

[Latisha L. <ear...@ya...>]

START EARNING the INCOME You Deserve Right Now

Tired of being turned down because you do not the right educational background?  Did you know that you are a qualified professional but simply lack the requested credentials after your name?  You know you deserve a better salary, more prestige but lack the Educational background  - even though you have the life's knowledge and the abilities requested in today's world?

Alternative Educational Backgrounds based upon your employment experiences and your ability. Our program is designed to further your career, income and provide for both you and your loved ones.  Stop watching helplessly as your co-workers pass you by.  Tired of being turned down because you do not the right educational background?

Waiting for your call now--203--286--2403

[Zopexmlmethods-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Zopexmlmethods-devel] transform() now takes keyword args

[Craeg K S. <cs...@ar...>]

I just committed a small change that makes it possible
to override XSLT parameters via keyword args, as in the
following example:

<div tal:replace="structure python:doc.contactsxsl(category = 
template.category)"/>

<xsl:stylesheet
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   version="1.0">

   <xsl:import href="urn:arielpartners:common/xslfragment/html/roles.xsl"/>

   <xsl:output
     method="html"
     indent="yes"
     encoding="utf-8"
     media-type="text/html"/>

   <xsl:param name="category">all</xsl:param>

... etc.

Unfortunately, the BrowseCVS feature on Sourceforge seems to be
way out of date.  So the only way to review this is to actually check 
out the code.

Philipp-- I think the last thing to put in place is the ability
to override parameters from the URL address bar:

http://foo.bar.com/doc/contractsxsl?category=PROJECTA

Do you have an ETA when you might be able to do this?

Also, what other burning issues must be addressed before we make a 1.1
release?  Besides the query params above, I have only one:

- documentation updates

Regards,

--Craeg

[Zopexmlmethods-devel] DTDValidateMethod first cut checked in, working

[Craeg K S. <cs...@ar...>]

All done and checked in.  from CHANGES.txt

- Created an XMLMethod base class for XSLTMethod, XPathMethod,
  and DTDValidateMethod. (CKS)

- Created a DTDValidateMethod class.  This will either be renamed to
  XMLValidateMethod or joined by SchematronValidateMethod,
  XMLSchemaValidateMethod, and RelaxNGValidateMethod in the future
  (CKS)

- Created a base IProcessor interface, only has setDebugLevel
  for now.

- Added IDTDValidator interface (for 4suite1.0a only, for now)
  (CKS)

- Removed transformGuts() from IXSLTProcessor interface.  Now
  transform() may throw an exception.

- Added XPathMethod, IXPathProcessor, IXPathExpression (CKS)
  (for 4suite1.0a only, for now)

- Renamed ProcessorChooser to ProcessorRegistry with refactored
  interface for better SoC (CKS)

- Upgraded tests for latest version of ExternalFile, v1.2 (CKS)


OK, I must now turn back to "Real Work"     :-}

Please take a look at the DTDValidateMethod and XPathMethod implementations.
I expect we will want to do some refactorings or renamings, but the 
ideas are there.

Having factored most stuff into the XMLMethod base class, they are 
pretty clean
looking.   They work fine for me on RedHat 9/Zope 2.6.1   I hope to test 
them
on my Win2K box, soon.

Comments welcome,

--Craeg

Re: [Zopexmlmethods-devel] Having trouble with SchemaValidator, how about DTDValidator

[Philipp v. W. <ph...@we...>]

Craeg K Strong wrote:

>> Yeah, quite crufty. However, first checking the XML whether any XML 
>> schema is mentioned and then offering a manual input seems the best 
>> solution for this problem. 
> 
> Yikes! Impossible. Remember that a single instance of
> xxxValidateMethod will be applied to *many* different XML documents.
> Some of those documents might explicitly mention a schema, some might
> not. In fact, you might add an xxxValidateMethod before *any* XML
> documents exist. Same as XSLTMethod and XPathMethod, no?

Yes, like XSLTMethod or XPathMethod.

> Oh. In the absence of anything else, I like Validator more, because
> it best describes what we are doing. However, if the interface
> becomes more general than that, I would support renaming. We can
> evolve this as necessary (at least until we make an official release
> :-)

+1

>>> Yes.   The choice is pretty simple:
>>> a) DTDValidateMethod, SchematronValidateMethod, etc. all inheriting 
>>> from a ValidateMethod base class (cleaner, more OO) or
>>> b) A single XMLValidateMethod class, and you set a property to
>>> indicate the validation method you wish. (less clean, but maybe less
>>> code, fewer externally visible moving parts)
>>
>> I'd go with b). 
> 
> Do you still vote for this, even after my "Yikes!" comment (above)?

I'd still prefer b) but I can see where you're coming from. So, lazy as 
I am, I leave the solution up to you :) Sorry, I know this doesn't help 
you...

>> I'd say zope:// sounds good, but I'm not sure whether we'd want 
>> file://. Maybe file:// would be zope:// and we wouldn't have to invent 
>> another protocol prefix? This would ease things for 3rd party products 
>> that would "mount" the ZODB over FTP, WebDAV or whatever and rever to 
>> the entities over the file:// protocol. 
> 
> Yeah.  This is getting into VFS territory.   This is not something I am 
> motivated to explore in Zope2.

But we'd still like to resolve URIs...

> However, I really think Zope3 needs to do something here. Of course,
> I am speaking from ignorance. There may already be good stuff going
> on there. My plan is to dive in as soon as the 3X beta happens ~ 1
> month(?)

There is nothing VFS-like in Zope3. There are traversal components, but 
HTTP, FTP and WebDAV interfaces are management by views, there's no 
VFS-layer (there actually existed one, but it was ripped out because it 
was not considered over-kill).

With respect to the "correct" time to dive into Zope3, I can only say: 
there's no "correct" time. I'm not sure whether the beta will be any 
more useful than the code right now. I am currently seeing a lot of 
refactorings going on, not actual additions to the code.

Phil

Re: [Zopexmlmethods-devel] Having trouble with SchemaValidator, how about DTDValidator

[Craeg K S. <cs...@ar...>]

Philipp von Weitershausen wrote:

> Craeg K Strong wrote:
>
>> Philipp von Weitershausen wrote:
>>   So if we had a "Schema-URI" property for our
>> "XMLValidateMethod" (I like that name) Zope object, then it could be
>> optional for DTD/XMLSchema, but mandatory for Schematron, for
>> example. I guess that's not so bad, if we make it clear in the docs.
>> Just a bit crufty, tho...
>
> Yeah, quite crufty. However, first checking the XML whether any XML 
> schema is mentioned and then offering a manual input seems the best 
> solution for this problem. 

Yikes! Impossible.  Remember that a single instance of xxxValidateMethod 
will be applied
to *many* different XML documents.  Some of those documents might 
explicitly mention a schema,
some might not.   In fact, you might add an xxxValidateMethod before 
*any* XML documents
exist.  Same as XSLTMethod and XPathMethod, no?

>>> Maybe we'd also like to call them Processor instead of Validator, in 
>>> order to be consistent with IXPathProcessor and IXSLTProcessor. 
>>
>> So, you are thinking there will be lots of other things to do with 
>> Schemas, such as automatically generating forms, python adaptor
>> classes, or whatnot. The stuff that is already being done in Zope3,
>> right? And you are thinking of adding these methods to the
>> IxxxSchemaProcessor interface rather than creating separate, smaller
>> interfaces. Hard to tell which is better, at this early stage, no?
>
> Heh, I was actually not thinking about ANY of these :) I was just 
> wondering whether it would be more consistent if we'd name the 
> interfaces IxxxSchemaProcessor instead of IxxxSchemaValidator because 
> they will be implemented by a *processor* (e.g. the FourSuiteProcessor). 

Oh.  In the absence of anything else, I like Validator more, because it 
best describes what we are doing.
However, if the interface becomes more general than that, I would 
support renaming.  We can evolve this
as necessary (at least until we make an official release :-)  

> Your ideas sound sweet, but to be honest, I doubt that they will be 
> any useful in Zope2. This is rather a Z3 thing since it comes with 
> automatic form generation and component architecture using adaptors. 

I understand.  Let's wait and see.  Someone may identify a compelling 
use case
for which we just can't wait for Zope3 :)      Of course, it would have 
to be something
that provided high value at reasonably low (coding) cost...

>>> Will there be an XMLValidateMethod object like XPathMethod or 
>>> XSLTMethod? Is this what you meant with "creating four small Zope 
>>> classes"? 
>>
>> Yes.   The choice is pretty simple:
>> a) DTDValidateMethod, SchematronValidateMethod, etc. all inheriting 
>> from a ValidateMethod base class (cleaner, more OO) or
>> b) A single XMLValidateMethod class, and you set a property to
>> indicate the validation method you wish. (less clean, but maybe less
>> code, fewer externally visible moving parts)
>
> I'd go with b). 

Do you still vote for this, even after my "Yikes!" comment (above)?

>> I think this goes without saying. In fact, I would say that the "zope
>>  object ID" such as what we have in XSLTMethod, is really just a
>> short cut for a "zope protocol" URI zope:foo/bar/mumble.xsl And you
>> can use the zope protocol, FTP, file, HTTP, or whatever other URI
>> protocol supported by your processsor of choice. Essentially,
>> ZopeXMLMethods has extended the processor libraries to understand
>> this addtional protocol. The Zope protocol features acquisition, etc.
>> Perhaps it is more correct to call it the ZODB protocol? dunno.
>
> I'd say zope:// sounds good, but I'm not sure whether we'd want 
> file://. Maybe file:// would be zope:// and we wouldn't have to invent 
> another protocol prefix? This would ease things for 3rd party products 
> that would "mount" the ZODB over FTP, WebDAV or whatever and rever to 
> the entities over the file:// protocol. 

Yeah.  This is getting into VFS territory.   This is not something I am 
motivated to explore in Zope2.
However, I really think Zope3 needs to do something here.  Of course, I 
am speaking from ignorance.
There may already be good stuff going on there.  My plan is to dive in 
as soon as the 3X beta happens ~ 1 month(?)

>> b) whether the zope base classe was listed first or not.
>
> yes. That rings a bell. I'm not an expert, but I now that you mention 
> it, I think that was the problem. 

OK, I think that is fairly easily avoided...

--Craeg

Re: [Zopexmlmethods-devel] Having trouble with SchemaValidator, how about DTDValidator

[Philipp v. W. <ph...@we...>]

Craeg K Strong wrote:
> Philipp von Weitershausen wrote:
> 
>> I know for a fact that XML-Schema uses an attribute like 
>> xsi:schemaLocations="someuri" in the document element to refer to a 
>> certain schema. 
> 
> OK, that's good to know. So if we had a "Schema-URI" property for our
> "XMLValidateMethod" (I like that name) Zope object, then it could be
> optional for DTD/XMLSchema, but mandatory for Schematron, for
> example. I guess that's not so bad, if we make it clear in the docs.
> Just a bit crufty, tho...

Yeah, quite crufty. However, first checking the XML whether any XML 
schema is mentioned and then offering a manual input seems the best 
solution for this problem.

> As per the @@FIXME, we will want to differentiate the names of the 
> methods (OK, I admit it.
> Sometimes I miss method overloading a la Java/C++).  Any suggestions?

I think we have to go with different method names. :(

>> Maybe we'd also like to call them Processor instead of Validator, in 
>> order to be consistent with IXPathProcessor and IXSLTProcessor. 
> 
> So, you are thinking there will be lots of other things to do with 
> Schemas, such as automatically generating forms, python adaptor
> classes, or whatnot. The stuff that is already being done in Zope3,
> right? And you are thinking of adding these methods to the
> IxxxSchemaProcessor interface rather than creating separate, smaller
> interfaces. Hard to tell which is better, at this early stage, no?

Heh, I was actually not thinking about ANY of these :) I was just 
wondering whether it would be more consistent if we'd name the 
interfaces IxxxSchemaProcessor instead of IxxxSchemaValidator because 
they will be implemented by a *processor* (e.g. the FourSuiteProcessor).

Your ideas sound sweet, but to be honest, I doubt that they will be any 
useful in Zope2. This is rather a Z3 thing since it comes with automatic 
form generation and component architecture using adaptors.

>> Will there be an XMLValidateMethod object like XPathMethod or 
>> XSLTMethod? Is this what you meant with "creating four small Zope 
>> classes"? 
> 
> Yes.   The choice is pretty simple:
> a) DTDValidateMethod, SchematronValidateMethod, etc. all inheriting from 
> a ValidateMethod base class (cleaner, more OO) or
> b) A single XMLValidateMethod class, and you set a property to
> indicate the validation method you wish. (less clean, but maybe less
> code, fewer externally visible moving parts)

I'd go with b).

> I think this goes without saying. In fact, I would say that the "zope
>  object ID" such as what we have in XSLTMethod, is really just a
> short cut for a "zope protocol" URI zope:foo/bar/mumble.xsl And you
> can use the zope protocol, FTP, file, HTTP, or whatever other URI
> protocol supported by your processsor of choice. Essentially,
> ZopeXMLMethods has extended the processor libraries to understand
> this addtional protocol. The Zope protocol features acquisition, etc.
> Perhaps it is more correct to call it the ZODB protocol? dunno.

I'd say zope:// sounds good, but I'm not sure whether we'd want file://. 
Maybe file:// would be zope:// and we wouldn't have to invent another 
protocol prefix? This would ease things for 3rd party products that 
would "mount" the ZODB over FTP, WebDAV or whatever and rever to the 
entities over the file:// protocol.

> It was something about
> a) how deep the inheritance hierarchy was, and/or

no, I don't think so.

> b) whether the zope base classe was listed first or not.

yes. That rings a bell. I'm not an expert, but I now that you mention 
it, I think that was the problem.

Phil

Re: [Zopexmlmethods-devel] Having trouble with SchemaValidator, how about DTDValidator

[Craeg K S. <cs...@ar...>]

Philipp von Weitershausen wrote:

> I know for a fact that XML-Schema uses an attribute like 
> xsi:schemaLocations="someuri" in the document element to refer to a 
> certain schema. 

OK, that's good to know.  So if we had a "Schema-URI" property for our 
"XMLValidateMethod"
(I like that name) Zope object, then it could be optional for 
DTD/XMLSchema, but mandatory
for Schematron, for example.   I guess that's not so bad, if we make it 
clear in the docs.  Just
a bit crufty, tho...

> IMO, we should have four *interfaces*:
>   * IDTDValidator
>   * IRelaxNGValidator
>   * ISchematronValidator
>   * IXMLSchemaValidator 

Yes, sorry, I was already assuming we had those.  In fact, I have 
started implementing
IDTDValidator:

class IDTDValidator(IProcessor):
    """
    ZopeXMLMethods DTD Validator public interface

    This class encapsulates an DTD Validator for use by
    ZopeXMLMethods.  IDTDValidator is the Interface implemented by a
    processor library.  Any library capable of validating XML via a
    DTD can be used, as long as an adaptor class is written that
    conforms to this interface.

    @@FIXME CKS 6/14/2003 This is the first of many schema validator
    interfaces.  For example: XML-Schema, RelaxNG, Schematron, DTD.
    Once we implement the others, this might need to be refactored.
    In particular, the method may need to be changed in order to make
    it possible for a single processor class to implement multiple
    Schema Validation interfaces.
   
    """

    def validationResultsString(xmlString, xmlURL):
        """
        Validate the passed in XML document against the
        DTD that it refers to in a DOCTYPE.
        """

    def isValid(xmlString, xmlURL):
        """
        Return boolean indicating whether passed in document is valid
        with respect to its DTD
        """

As per the @@FIXME, we will want to differentiate the names of the 
methods (OK, I admit it.
Sometimes I miss method overloading a la Java/C++).  Any suggestions?

>
> If you want, they could all inherit from a marker interfaces called 
> IValidator, but that's overkill.

Yep.  Here is all I could come up with so far.  Everybody else inherits 
from this:

class IProcessor(Interface):

    def setDebugLevel(level):
        """

        Set debug level from 0 to 3.
        0 = silent
        3 = extra verbose
        Debug messages go to Zope server log.

        """

> Maybe we'd also like to call them Processor instead of Validator, in 
> order to be consistent with IXPathProcessor and IXSLTProcessor. 

So, you are thinking there will be lots of other things to do with Schemas,
such as automatically generating forms, python adaptor classes, or whatnot.
 The stuff that is already being done in Zope3, right?  And you are 
thinking of adding these
methods to the IxxxSchemaProcessor interface rather than creating 
separate, smaller interfaces.
Hard to tell which is better, at this early stage, no?

> If a processor implements any of these, it promises that it can do 
> this kind of validation (just like with IXPathProcessor). Please keep 
> in mind that those interfaces may not declare any methods of the same 
> name, because it might very well be that a processor supports more 
> than one validation. 

indeed. see @@FIXME above....

> I'm a little confused about your further questions. First, I think 
> it's too early to talk about how we design management pages before we 
> don't have a clear picture of the interfaces; second, I'm not sure 
> how, where and with what you would like to do the validation. 

Oops, sorry, I have been moving kinda fast because I have about one more 
day to
work on this, and then I have to get back to "Real Work."   All I need 
for what I am working on
today is something to give me the results of validating an XML document 
against its DTD.

If I had a zope object that was an instance of XMLValidateMethod or 
DTDValidateMethod
called "validate" then I could do this:

foo/bar/mydoc/validate

And see a web page listing the results of the validation.    That is not 
the last of my ambition,
but it will enable me to get started on the vision described below:

I am trying to put together a 100% zope/web based document management 
solution that
is also 100% XML and ZPT, and stores all of the XML documents in a 
revision control
system like Clearcase or CVS.  Of course, we want support editing 
documents in OpenOffice
and saving to DocBook, but as a first baby step I want to support 
editing documents in
raw XML.  I have to be able to validate the documents.   Otherwise when 
I try to apply
XSLTMethods to them they die all sorts of horrible deaths.   This is my 
(set of) use case(s).
I can (almost) do this today with CVSFile and ZopeXMLMethods.

>
> Will there be an XMLValidateMethod object like XPathMethod or 
> XSLTMethod? Is this what you meant with "creating four small Zope 
> classes"? 

Yes.   The choice is pretty simple:
a) DTDValidateMethod, SchematronValidateMethod, etc. all inheriting from 
a ValidateMethod
base class (cleaner, more OO) or
b) A single XMLValidateMethod class, and you set a property to indicate 
the validation
method you wish.  (less clean, but maybe less code, fewer externally 
visible moving parts)

>> Also, we need a field for the "Schema Object ID" *only* if it is
>> not a DTD.
>
> We don't want to limit this to an object ID, IMO. When we implemented 
> basic XML-Schema support in Zope3, we followed what XML-Schema and 
> probably all other standards use: URIs. The schema may be another Zope 
> object, but it could also be an external source like a W3C XHTML 
> Doctype which you would not like to copy to your Zope instance, but 
> rather refer to it using a URI like http://www.w3.org/DTDs/wherever/it/is 

I think this goes without saying.   In fact, I would say that the "zope 
object ID" such as
what we have in XSLTMethod, is really just a short cut for a "zope 
protocol" URI
zope:foo/bar/mumble.xsl
And you can use the zope protocol, FTP, file, HTTP, or whatever other 
URI protocol
supported by your processsor of choice.  Essentially, ZopeXMLMethods has 
extended
the processor libraries to understand this addtional protocol.  The Zope 
protocol features
acquisition, etc.  Perhaps it is more correct to call it the ZODB 
protocol? dunno.
Compare this to the FourThought 4Suite product, where the 4suite repository
has analogous features but they officially call it out using URIs like
this: "ftss://foo/bar/mumble.xml"

> Since DTD, XML-Schema (and probably the other standards, too) support 
> declaring their schema using a URI, I think the default setting for 
> the validator should be: extract the URI from the document, resolve 
> the URI, fetch the object (that's going to be a little work, because 
> eventually, we'd like to support URIs from HTTP; for now, we can just 
> support relative URIs which will be resolved to Zope objects using 
> restrictedTraverse()) and evaluate it.
> When that whole chain fails, either because there is no URI 
> declaration, or the URI leads to nothing, you should be able to enter 
> a different URI. 

yep.

>> The alternative is four small classes.  Problem is in Zope2 inheritance
>> is broken, so we can't create a Validator base class, right?  IIRC
>> this is because of the fact that Zope2 uses a special base class
>> for persistence written in C that does not obey all of the normal
>> Python rules wrt inheritance.
>
>
> I think you're confusing things here. It is correct that persistent 
> classes with ZODB3 (i.e. Zope2) use ExtensionClass as the ultimate 
> base class which in some circumstances behaves differently than 
> standard python classes, but inheritance is still working! 

OK, my memory is really fuzzy on this one.  I vaguely remember something 
we did
about a year ago where we had all kinds of problems.  Correct me if I am 
wrong here,
but I will attempt to dredge up with the use case.

Consider a class A and a class B

class A(Folder): # a "zope" class (i.e it ultimately inherits from 
ExtensionClass)
class B: # not "" "" ""

class myZopeClass(B, A): # WILL NOT WORK

class myZopeClass(A, B): # OK, this works

It was something about
a) how deep the inheritance hierarchy was, and/or
b) whether the zope base classe was listed first or not.

Does this ring any bells?  #(*@! I wish I had written down the issue 
when I first
ran into it many moons ago.....

Thanks,

--Craeg

Re: [Zopexmlmethods-devel] Having trouble with SchemaValidator, how about DTDValidator

[Philipp v. W. <ph...@we...>]

Craeg,

> Here are the forces:
> 
> - there are many types of schemas: DTD, RelaxNG, Schematron, XML-Schema
> - the changes any given processor library will implement *all four* are 
> virtually nil
> - DTD is different b/c it is mentioned in the document, the others are
> linked externally

That is not entirely true. First, DTD can be declared *in* the XML 
document (inline), but as a separate entity using the PUBLIC or SYSTEM 
identifier. Second, I know for a fact that XML-Schema uses an attribute 
like xsi:schemaLocations="someuri" in the document element to refer to a 
certain schema.

> These forces are leading me towards creating four small Zope classes:
> DTDValidator, RelaxNGValidator, SchematronValidator, XMLSchemaValidator.

I would like to follow the path we have chosen for XPathMethods here.

IMO, we should have four *interfaces*:
   * IDTDValidator
   * IRelaxNGValidator
   * ISchematronValidator
   * IXMLSchemaValidator
If you want, they could all inherit from a marker interfaces called 
IValidator, but that's overkill. Maybe we'd also like to call them 
Processor instead of Validator, in order to be consistent with 
IXPathProcessor and IXSLTProcessor.

If a processor implements any of these, it promises that it can do this 
kind of validation (just like with IXPathProcessor). Please keep in mind 
that those interfaces may not declare any methods of the same name, 
because it might very well be that a processor supports more than one 
validation.

I'm a little confused about your further questions. First, I think it's 
too early to talk about how we design management pages before we don't 
have a clear picture of the interfaces; second, I'm not sure how, where 
and with what you would like to do the validation.
Will there be an XMLValidateMethod object like XPathMethod or 
XSLTMethod? Is this what you meant with "creating four small Zope classes"?

> Also, we need a field for the "Schema Object ID" *only* if it is
> not a DTD.

We don't want to limit this to an object ID, IMO. When we implemented 
basic XML-Schema support in Zope3, we followed what XML-Schema and 
probably all other standards use: URIs. The schema may be another Zope 
object, but it could also be an external source like a W3C XHTML Doctype 
which you would not like to copy to your Zope instance, but rather refer 
to it using a URI like http://www.w3.org/DTDs/wherever/it/is

Since DTD, XML-Schema (and probably the other standards, too) support 
declaring their schema using a URI, I think the default setting for the 
validator should be: extract the URI from the document, resolve the URI, 
fetch the object (that's going to be a little work, because eventually, 
we'd like to support URIs from HTTP; for now, we can just support 
relative URIs which will be resolved to Zope objects using 
restrictedTraverse()) and evaluate it.
When that whole chain fails, either because there is no URI declaration, 
or the URI leads to nothing, you should be able to enter a different URI.

> The alternative is four small classes.  Problem is in Zope2 inheritance
> is broken, so we can't create a Validator base class, right?  IIRC
> this is because of the fact that Zope2 uses a special base class
> for persistence written in C that does not obey all of the normal
> Python rules wrt inheritance.

I think you're confusing things here. It is correct that persistent 
classes with ZODB3 (i.e. Zope2) use ExtensionClass as the ultimate base 
class which in some circumstances behaves differently than standard 
python classes, but inheritance is still working!

Hope that helps,

Philipp

[Zopexmlmethods-devel] Having trouble with SchemaValidator, how about DTDValidator

[Craeg K S. <cs...@ar...>]

Hello:

Here are the forces:

- there are many types of schemas: DTD, RelaxNG, Schematron, XML-Schema
- the changes any given processor library will implement *all four* are 
virtually nil
- DTD is different b/c it is mentioned in the document, the others are
linked externally

These forces are leading me towards creating four small Zope classes:
DTDValidator, RelaxNGValidator, SchematronValidator, XMLSchemaValidator.

== or ==

we will have a complex property management page in the ZMI.
It will have to list all of the available *combinations* of
schema types and processors:

<choose one>
4suite DTD
4Suite RelaxNG
Libxslt DTD
Libxslt XML-Schema
Sablotron DTD

Or we do a fancy UI with Javascript with two seperate menus that
respond to each other dynamically.  That is not in keeping with the
standard ZMI look and feel.

Also, we need a field for the "Schema Object ID" *only* if it is
not a DTD.

yuk.

The alternative is four small classes.  Problem is in Zope2 inheritance
is broken, so we can't create a Validator base class, right?  IIRC
this is because of the fact that Zope2 uses a special base class
for persistence written in C that does not obey all of the normal
Python rules wrt inheritance.   Of course, we could create a Validator
interface and put the shared methods there....

Thoughts?

--Craeg

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_Re:_[Zopexmlmethods-devel]_Interface_for_XPathMethod=3F?=

[Craeg S. <cs...@ar...>]

OK, see below:

Here's a use-case for the ProcessorRegistry I 
> have in mind:
> 
> Somebody writes a new XSLT processor and a class that implements our 
> IXSLTProcessor interface in his own party. He would now like to use this 
> processor in XSLTMethod. Here is now I would like to see this:
> 
> from Products.ZopeXMLMethods.interfaces import IXSLTProcessor
> 
> class CustomProcessor:
>    __implements__ = IXSLTProcessor
>    ...
> 
> # processorRegistry is a singleton instance of ProcessorRegistry
> from Products.ZopeXMLMethods.ProcessorRegistry import processorRegistry
> # register sees what interfaces CustomProcessor implements and figures
> # out the rest
> processorRegistry.register(CustomProcessor)
> 

OK I am about to check in the XPathMethod initial
implementation.  It needs a bit more cleanup,
but it works.  Specifically, there are some
duplicated methods that should be factored
out into a utility module somewhere so no
duplication between XSLTMethod.py and XPathMethod.py

Feel free to chisel away at it, if you can
beautify it or simplify.  I still need to test
the __reduce__/__getstate__/__setstate__
code to make sure that makes it possible to ZSync
instances to a Zope without the same processor.
I have not tested that yet....

Regards,

--Craeg

Re: [Zopexmlmethods-devel] Interface for XPathMethod?

[Philipp v. W. <ph...@we...>]

Craeg,

> I have refactored ProcessorChooser heavily and renamed
> it to ProcessorRegistry.  However, I am unable to 
> make it a mirror image of GeneratorRegistry.  The 
> reason is that it does lazy loading.  Worse, even.
> It can *never* hold an instance of a processor,
> because then it would make ZSyncing across
> processors impossible.  So making Processors register
> themselves once at runtime won't work.

Okay, that makes sense. There must be some otherway to actually hold the 
classes. Either the ProcessorRegistry must be hold lazyly oder the 
classes. Maybe a special __reduce__ method which would not include those 
processor classes would solve the problem (I really think so!)

> So my refactorings don't end up changing much.  Basically
> I cleaned up the interface and made it more orthogonal,
> and changed to using compile() and exec() to eliminate
> the explicit calls to specific processors.  In the 
> end, however, I wonder if its really more readable
> or maintainable.

You're right, you haven't changed much in the end (it looks different, 
but works the same way). Here's a use-case for the ProcessorRegistry I 
have in mind:

Somebody writes a new XSLT processor and a class that implements our 
IXSLTProcessor interface in his own party. He would now like to use this 
processor in XSLTMethod. Here is now I would like to see this:

from Products.ZopeXMLMethods.interfaces import IXSLTProcessor

class CustomProcessor:
   __implements__ = IXSLTProcessor
   ...

# processorRegistry is a singleton instance of ProcessorRegistry
from Products.ZopeXMLMethods.ProcessorRegistry import processorRegistry
# register sees what interfaces CustomProcessor implements and figures
# out the rest
processorRegistry.register(CustomProcessor)

>     def prefer(self, processorType, processorName, exclusive=0):
>         """
>         For a given processor type, indicate a preference for one
>         processor over another.  Set the 'exclusive' flag to indicate
>         that no other choices should be offered, even if available.
>         To change your preference, simply call this method again.
>         
>         Note: if the chosen processor is not available, this advice is
>         simply ignored.  Why?  Imagine the case where you make a
>         choice, then ZSync the object tree to another Zope instance in
>         which this processor is not available!  We must recover
>         gracefully from this (rather likely) scenario.
>         """
>         self._preferred[processorType.__name__] = (processorName,exclusive)

I don't like this __name__ business. Why not deal with the interface 
directly? Interfaces provide much nicer ways to determine whether a 
class is "of a certain type" (i.e. whether a class implements that 
interface). Also, this approach is more Component Architecture-like, 
thus making it easier to port it to Zope3 eventually.

> def InstantiateProcessor(processorClassName, processorName):
>     """
>         
>     Instantiate a processor of the type whose class name is passed
>     in and return it.
> 
>     Log an error to stdout (the zope log) in case of an Exception,
>     and return None
>         
>     """
> 
>     try:
>         importStatement = "from %s import %s" % ( processorClassName,
>                                                   processorClassName )
>         code   = compile(importStatement, 'Processors.py', 'exec')
>         exec(code)
>         clazz = eval(processorClassName)
>         proc  = apply(clazz, ())
>         return proc

This can be done in a more elegant way:

try:
   klass = __import__(processorClassName, globals(),
                      locals(), [processorClassName])
   proc = klass()
   return proc
except:
   ...

Although I still think that it should be possible to register classes 
instead of names. This way we don't have to rely on some special naming 
(and placing) convention for processor classes (see the above use case).

Phil

[Zopexmlmethods-devel] =?iso-8859-1?Q?Re:_Re:_[Zopexmlmethods-devel]_Interface_for_XPathMethod=3F?=

[Craeg S. <cs...@ar...>]

>I would vote for this:
> 
> class IXPathProcessor(Interface):
> 
>      def compile(expression):
>          "return compiled expression as IXPathExpression"
> 
> class IXPathExpression(Interface):
> 
>      def evaluateString(xmlString, xmlURL, xpath):
>         "return result of xpath evaluation as string"
>         # doesn't have to be pretty printed
> 
>      def evaluateDOM(xmlNode, xmlURL, xpath):
>         "return a list of DOM nodes matching xpath"

OK Thats done.

> a compiletime notion of whether a particular
> > processor supports feature X ... I guess we just say 
> >   if IXPathProcessor.isImplementedBy(processor):
> >      # try it...
> 
> Well, since we're going into the guts of ProcessorChooser anyway, I vote 
> for turning ProcessorChooser into ProcessorRegistry (doesn't have to be 
> renamed, although I would favour it), which would work similar to my 
> GeneratorRegistry.
> It just provides a facility to register processor and query them 
> according to certain implementation features. I think we should not 
> query for strings like 'xslt', 'xpath', 'dtd', but for interfaces 
> (IXSLTProcessor, IXPathProcessor, etc.). That way we solve your issue a) 
> right at its root and b) becomes obsolent, because processors register 
> themselves (like my object Generators).

I have refactored ProcessorChooser heavily and renamed
it to ProcessorRegistry.  However, I am unable to 
make it a mirror image of GeneratorRegistry.  The 
reason is that it does lazy loading.  Worse, even.
It can *never* hold an instance of a processor,
because then it would make ZSyncing across
processors impossible.  So making Processors register
themselves once at runtime won't work.  

So my refactorings don't end up changing much.  Basically
I cleaned up the interface and made it more orthogonal,
and changed to using compile() and exec() to eliminate
the explicit calls to specific processors.  In the 
end, however, I wonder if its really more readable
or maintainable.

If you get a chance, could you take a glance at the
attached code?   I think it might be on the borderline
of being over-engineered...

Thanks,

--Craeg

> 
> Thoughts?
> 
> Philipp
> 
> 

Re: [Zopexmlmethods-devel] Interface for XPathMethod?

[Philipp v. W. <ph...@we...>]

Craeg Strong wrote:
> It seems that most processors have encapsulated
> XPath expressions in a type, and have a notion of 
> pre-compiling them, all except for Sablotron.

That's why I would vote for this:

class IXPathProcessor(Interface):

     def compile(expression):
         "return compiled expression as IXPathExpression"

class IXPathExpression(Interface):

     def evaluateString(xmlString, xmlURL, xpath):
        "return result of xpath evaluation as string"
        # doesn't have to be pretty printed

     def evaluateDOM(xmlNode, xmlURL, xpath):
        "return a list of DOM nodes matching xpath"
        # yes, this would probably only be useful for 4Suite...

All except Sablotron would wrap their expression type in an object 
implementing IXPathExpression. For Sablotron, that object simply stores 
the expression in itself.
I think this makes it cleaner and people are used to this kind of 
semantics for example from the re package (x = re.compile(...); 
x.match(...))

> As a matter of fact, how about I start out implementing
> only FourSuite, and simply leave the other processors
> _not_ implementing IXPathProcessor for now.

Sounds good.

> That's interesting, because now we need to know both
> 
> a) a compiletime notion of whether a particular
> processor supports feature X (either yes, no, or
> yes but we haven't implemented it yet)
 >
> b) a runtime notion of whether a particular processor
> is currently installed
> 
> For (a) I guess we just say 
>   if IXPathProcessor.isImplementedBy(processor):
>      # try it...

Well, since we're going into the guts of ProcessorChooser anyway, I vote 
for turning ProcessorChooser into ProcessorRegistry (doesn't have to be 
renamed, although I would favour it), which would work similar to my 
GeneratorRegistry.
It just provides a facility to register processor and query them 
according to certain implementation features. I think we should not 
query for strings like 'xslt', 'xpath', 'dtd', but for interfaces 
(IXSLTProcessor, IXPathProcessor, etc.). That way we solve your issue a) 
right at its root and b) becomes obsolent, because processors register 
themselves (like my object Generators).

Thoughts?

Philipp

[Zopexmlmethods-devel] =?iso-8859-1?Q?Interface_for_XPathMethod=3F?=

[Craeg S. <cs...@ar...>]

It seems that most processors have encapsulated
XPath expressions in a type, and have a notion of 
pre-compiling them, all except for Sablotron.

Of course, each processor has its own special type,
and we don't want to expose that to XPathMethod.

What about this for an interface:

IXPathProcessor

  def compile(expression):
     "return handle to compiled expression or expr itself"

  def evaluate(xmlString, xmlURL, xpath):
     "return pretty printed result of xpath evaluation"

Eventually, all of the processors can implement
both IXSLTProcessor and IXPathProcessor.

As a matter of fact, how about I start out implementing
only FourSuite, and simply leave the other processors
_not_ implementing IXPathProcessor for now.

Then we have to extend ProcessorChooser to understand
interfaces-- you ask "tell me the list of processors
available for XXX" where XXX is xpath, xslt, dtd, etc.

That's interesting, because now we need to know both

a) a compiletime notion of whether a particular
processor supports feature X (either yes, no, or
yes but we haven't implemented it yet)

b) a runtime notion of whether a particular processor
is currently installed

For (a) I guess we just say 
  if IXPathProcessor.isImplementedBy(processor):
     # try it...

Thoughts?

--Craeg

[Zopexmlmethods-devel] =?iso-8859-1?Q?libxslt_with_python_2.2/win32_and_zope_2.6.1_setup?=

[Craeg S. <cs...@ar...>]

> Craeg Strong wrote:
> > Thanks for the information! 
> >
> > You have found an innovative solution
> > to the problem that Zope currently does not
> > support Python 2.2, while the latest libxslt uses it!
>
> Does it? I can't see where it *requires* it.

I believe it is purely an installation issue for win32.
I think it looks for python 2.2 in the registry.
I dunno, I haven't really tried it.  If the latest
releases of libxslt *do* work with python 2.1.x, they
sure don't advertise it...

>
> > I have heard rumors that the next point release of
> > Zope 2.6 will support Python 2.2, and that would
> > likely be available in the next 1-3 months.
>
> There are still a lot of problems with Zope 2.X and Python 2.2, even in
> 2.7. For example, starting with Python 2.2, builtin types have
> docstrings, thus the ZPublisher can publish them. While everyone agrees
> that the ZPublisher's policy of using the docstring is stupid, the
> problem remains.

Actually, according to recent traffic on zope-dev this
problem was recently fixed IIRC.  Further, the fix may have
happened in the 2.6.X branch.  We may yet get Python 2.2
support in the near future!

> I believe 2.1 is currently the best platform for Zope 2.

Agreed.  Sigh.

> Philipp
>
> P.S.: I can't see any advancements on the XSLT parameters issue. I have
> safely arrived in Mexico and have some time now. Do you guys still want
> me to tackle this problem?
>
Yes, Please :)

--Craeg

[Zopexmlmethods-devel] Re: [Zopexmlmethods-users] libxslt with python 2.2/win32 and zope 2.6.1 setup

[Philipp v. W. <ph...@we...>]

Craeg Strong wrote:
> Thanks for the information!  
> 
> You have found an innovative solution 
> to the problem that Zope currently does not
> support Python 2.2, while the latest libxslt uses it!

Does it? I can't see where it *requires* it.

> I have heard rumors that the next point release of
> Zope 2.6 will support Python 2.2, and that would
> likely be available in the next 1-3 months.

There are still a lot of problems with Zope 2.X and Python 2.2, even in 
2.7. For example, starting with Python 2.2, builtin types have 
docstrings, thus the ZPublisher can publish them. While everyone agrees 
that the ZPublisher's policy of using the docstring is stupid, the 
problem remains.

> I think if we release ZopeXMLMethods 1.1 _before_
> this happens, we will want to include your information
> in the README documentation.  However, I would
> prefer to simply switch to Python 2.2 across the
> board if possible.

No, I would not prefer to do that. See below.

>>Step 3 :
>>now working with Zope 
>>(Zope 2.6.0 (binary release, python 2.1, win32-x86), python 2.1.3, win32) 
>>first i try to use the python 2.2 bidings for python 2.1.3 in Zope 
>>but have a import Error message. that's right.
>>So try to install python 2.1 binding  the installer is not abble to find installation directory.
>>I use regedit to help him. ( that's not my favorite sport !!!)

Well, that's a Windows problem. But you did the right thing and pointed 
the libxml installer to your Zope's python (which is likely not 
registered in the registry)

>>According to sys.path I install the librairy to [Zope]\bin\lib.  
>>
>>try first example of ZopeXMLMethods tutorial
>>nice Hello world message. 

So, where's the problem? Everything's working now. Why should we require 
Python 2.2 then? Most people are running Zope 2.6 with 2.1.3 and just 
because they want to use *one* of many possible XSLT processors, they 
all of a sudden have to switch to Python 2.2 now?

Don't get me wrong, I'm a big fan of Python 2.2 (and 2.3 even more), but 
I believe 2.1 is currently the best platform for Zope 2.

Philipp

P.S.: I can't see any advancements on the XSLT parameters issue. I have 
safely arrived in Mexico and have some time now. Do you guys still want 
me to tackle this problem?

[Zopexmlmethods-devel] =?iso-8859-1?Q?libxslt_with_python_2.2/win32_and_zope_2.6.1_setup?=

[Craeg S. <cs...@ar...>]

Thanks for the information!  

You have found an innovative solution 
to the problem that Zope currently does not
support Python 2.2, while the latest libxslt uses it!

I have heard rumors that the next point release of
Zope 2.6 will support Python 2.2, and that would
likely be available in the next 1-3 months.

I think if we release ZopeXMLMethods 1.1 _before_
this happens, we will want to include your information
in the README documentation.  However, I would
prefer to simply switch to Python 2.2 across the
board if possible.

In any event, I am forwarding this message to our
mailing lists in the hope that others might find it
useful in the interim.  Thanks again!

--Craeg

> more info about libxslt with ZopeXMLMethods
> Step 1 :
> without python, i am using libxslt on windows 98 and it work very fine.
> installing :libxml2-2.4.23.win32.zip, libxslt-1.0.19.win32.zip
> AND iconv-1.8.win32.zip
> and put the .dll in c:\windows
> Testing with xsltproc.exe include in the libxslt zip file
> 
> Step 2 :
> Now with python 2.2 but without Zope.
>  installing libxml2-python-2.5.7.win32-py2.2.exe python  bindings (python 2.2)
> from http://users.skynet.be/sbi/libxml-python/ 
> ( this download include the .dll no need to go at http://www.zlatkovic.com/) 
> basic test of XSLT interfaces (basic.py file example find at http://www.xmlsoft.org/XSLT/python.html) : no problem
> 
> Step 3 :
> now working with Zope 
> (Zope 2.6.0 (binary release, python 2.1, win32-x86), python 2.1.3, win32) 
> first i try to use the python 2.2 bidings for python 2.1.3 in Zope 
> but have a import Error message. that's right.
> So try to install python 2.1 binding  the installer is not abble to find installation directory.
> I use regedit to help him. ( that's not my favorite sport !!!)
> According to sys.path I install the librairy to [Zope]\bin\lib.  
> 
> try first example of ZopeXMLMethods tutorial
> nice Hello world message. 
> 
> I'am agree if this can help you. Sorry for my very bad English i leave in France.
> 

[Zopexmlmethods-devel] OSCOM?

[Brent H. <br...@ec...>]

Anybody going to OSCOM in Boston next week?  I'll be there, and I 
thought if anyone else planned on going we could meet up.  Maybe hold a 
ZopeXMLMethods hacking session :)

-- Brent

-------------------------------------------------------------------------

"The programmer, like the poet, works only slightly removed from pure
  thought-stuff.  He builds his castles in the air, from air, creating
  by exertion of the imagination.  Few media of creation are so
  flexible, so easy to polish and rework, so readily capable of
  realizing grand conceptual structures."
                         -- Frederick Brooks, Jr., The Mythical Man Month

Re: [Zopexmlmethods-devel] Override variable definitions via query string?

[Philipp v. W. <ph...@we...>]

Brent M Hendricks wrote:
>>> kw.update(REQUEST.form)
>>
>> Please correct me if I'm wrong but I don't think REQUEST.form is quite 
>> enough because it only contains form values. We'd need at least 
>> REQUEST.other, but looking at the (quite ugly) code of HTTPRequest, 
>> I'd say:
>> form
>> cookies
>> environ
>> other
> 
> I think that might be overkill.  Just because something appears in 
> REQUEST doesn't make it an automatic candidate for stylesheet 
> parameters.  There is a definite use case for REQUEST.form and I could 
> probably make one for REQUEST.cookies.  But the others strike me as 
> unnecessary and even unwanted, since neither the user nor the stylesheet 
> creator has direct control over them.

You're right, looking at it from the use case perspective is probably a 
better way. However, I think that the REQUEST.others dict does contain 
useful information, or where are GET parameters written to? REQUEST.form?

Anyhow, I'm sorry to say that I'm running out of time. I'm in the middle 
of packing things for Mexico. I don't think I'll be able to make the 
changes. Sorry.

Philipp