|
From: Craeg K S. <cs...@ar...> - 2003-06-15 23:00:51
|
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
|
