From dethe at burningtiger.com Thu Nov 1 01:49:34 2001 From: dethe at burningtiger.com (Dethe Elza) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Canonical Python DOM Interface (LONG) References: Message-ID: <3BE0F07E.70706@burningtiger.com> OK, here's my stab at it. I've taken the W3C DOM level 3 IDL file and converted it to Python according to the ODL Python mapping as best I could. Not entirely sure about DOMObject or DOMString. This process helped me to understand what the various DOM implementations are doing--I hadn't realized that the IDL mapping mandated _get_name() and _set_name() for attribute mappings, so when I saw that in various DOMs I assumed those were private methods that were implementation dependent. Ugly. To clarify, I'm not looking to test implementations functionally, I know there are already good test suites for that. What I'm interested in is in documenting the common ground between all the various Python DOM implementations, which requires knowing what the canonical mapping is, and being able to test how well a given implementation's collection of method signatures fits against that mapping (modulo versions). Given that, the IDL for DOM 2 might have been a better fit, but I like to live dangerously. Please let me know if anyone else finds this helpful. Also clarifying any mistakes, wrong assumptions, etc. would be very much appreciated. I have included type information in docstrings, but I couldn't (after a cursory search of the python docs) find the proper/official way to do this, so I winged it. ---------------- begin dom3.py ------------------------------ # DOMString represents a tuple of ints # DOMTimeStamp represents a long int value # DOMObject represents any object ??? # Dummy class to hold CORBA.TRUE and CORBA.FALSE class CorbaBoolean: pass CORBA = CorbaBoolean() CORBA.TRUE = 1 CORBA.FALSE = 2 class DOMException(Exception): code = 0 # int # ExceptionCode INDEX_SIZE_ERR = 1 DOMSTRING_SIZE_ERR = 2 HIERARCHY_REQUEST_ERR = 3 WRONG_DOCUMENT_ERR = 4 INVALID_CHARACTER_ERR = 5 NO_DATA_ALLOWED_ERR = 6 NO_MODIFICATION_ALLOWED_ERR = 7 NOT_FOUND_ERR = 8 NOT_SUPPORTED_ERR = 9 INUSE_ATTRIBUTE_ERR = 10 # Introduced in DOM Level 2: INVALID_STATE_ERR = 11 # Introduced in DOM Level 2: SYNTAX_ERR = 12 # Introduced in DOM Level 2: INVALID_MODIFICATION_ERR = 13 # Introduced in DOM Level 2: NAMESPACE_ERR = 14 # Introduced in DOM Level 2: INVALID_ACCESS_ERR = 15 class DOMImplementationSource : def getDOMImplementation(features): ''' returns DOMImplementation Args: features: DOMString ''' class DOMImplementation : def hasFeature(feature, version): ''' returns boolean Args: feature: DOMString version: DOMString ''' # Introduced in DOM Level 2: def createDocumentType(qualifiedName, publicId, systemId): ''' returns DocumentType Args: qualifiedName: DOMString publicId: DOMString systemId: DOMString raises DOMException ''' # Introduced in DOM Level 2: def createDocument(namespaceURI, qualifiedName, doctype): ''' returns Document Args: qualifiedName: DOMString doctype: DocumentType raises DOMException ''' # Introduced in DOM Level 3: def getInterface(feature): ''' returns DOMImplementation Args: feature: DOMString ''' class Node : # NodeType ELEMENT_NODE = 1 ATTRIBUTE_NODE = 2 TEXT_NODE = 3 CDATA_SECTION_NODE = 4 ENTITY_REFERENCE_NODE = 5 ENTITY_NODE = 6 PROCESSING_INSTRUCTION_NODE = 7 COMMENT_NODE = 8 DOCUMENT_NODE = 9 DOCUMENT_TYPE_NODE = 10 DOCUMENT_FRAGMENT_NODE = 11 NOTATION_NODE = 12 #readonly attribute nodeName def _get_nodeName(): ''' return DOMString ''' #attribute nodeValue def _get_nodeValue(): ''' returns DOMString raises DOMException ''' def _set_nodeValue(nodeValue): ''' returns None Args: nodeValue: DOMString raises DOMException ''' #readonly attribute nodeType def _get_nodeType(): ''' returns int ''' #readonly attribute parentNode def _get_parentNode(): ''' returns Node ''' #readonly attribute childNodes def _get_childNodes(): ''' returns NodeList ''' #readonly attribute firstChild def _get_firstChild(): ''' returns Node ''' #readonly attribute lastChild def _get_lastChild(): ''' returns Node ''' #readonly attribute previousSibling def _get_previousSibling(): ''' returns Node ''' #readonly attribute nextSibling def _get_nextSibling(): ''' returns Node ''' #readonly attribute attributes def _get_attributes(): ''' returns NamedNodeMap ''' # Modified in DOM Level 2: #readonly attribute ownerDocument def _get_ownerDocument(): ''' returns Document ''' # Modified in DOM Level 3: def insertBefore(newChild, refChild): ''' returns Node Args: newChild: Node refChild: Node raises DOMException ''' # Modified in DOM Level 3: def replaceChild(newChild, oldChild): ''' returns Node Args: newChild: Node oldChild: Node raises DOMException ''' # Modified in DOM Level 3: def removeChild(oldChild): ''' returns Node Args: oldChild: Node raises DOMException ''' def appendChild(newChild): ''' returns Node Args: newChild: Node raises DOMException ''' def hasChildNodes(): ''' returns boolean ''' def cloneNode(deep): ''' returns Node Args: deep: boolean ''' # Modified in DOM Level 2: def normalize(): ''' returns None ''' # Introduced in DOM Level 2: def isSupported(feature, version): ''' returns boolean Args: feature: DOMString version: DOMString ''' # Introduced in DOM Level 2: #readonly attribute namespaceURI def _get_namespaceURI(): ''' returns DOMString ''' # Introduced in DOM Level 2: #attribute prefix def _get_prefix(): ''' returns DOMString ''' def _set_prefix(prefix): ''' returns None Args: prefix: DOMString raises DOMException ''' # Introduced in DOM Level 2: #readonly attribute localName def _get_localName(): ''' returns DOMString ''' # Introduced in DOM Level 2: def hasAttributes(): ''' returns boolean ''' # Introduced in DOM Level 3: #readonly attribute baseURI def _get_baseURI(): ''' returns DOMString ''' # TreePosition TREE_POSITION_PRECEDING = 0x01 TREE_POSITION_FOLLOWING = 0x02 TREE_POSITION_ANCESTOR = 0x04 TREE_POSITION_DESCENDANT = 0x08 TREE_POSITION_SAME = 0x10 TREE_POSITION_EXACT_SAME = 0x20 TREE_POSITION_DISCONNECTED = 0x00 # Introduced in DOM Level 3: def compareTreePosition(other): ''' returns int Args: other: Node raises DOMException ''' # Introduced in DOM Level 3: #attribute textContent def _get_textContent(): ''' returns DOMString raises DOMException ''' def _set_textContent(textContent): ''' returns None Args: textContent: DOMString raises DOMException ''' # Introduced in DOM Level 3: def isSameNode(other): ''' returns boolean Args: other: Node ''' # Introduced in DOM Level 3: def lookupNamespacePrefix(namespaceURI): ''' returns DOMString Args: namespaceURI: DOMString ''' # Introduced in DOM Level 3: def lookupNamespaceURI(prefix): ''' returns DOMString Args: prefix: DOMString ''' # Introduced in DOM Level 3: def normalizeNS(): ''' returns None ''' # Introduced in DOM Level 3: def isEqualNode(arg, deep): ''' returns boolean Args: arg: Node deep: boolean ''' # Introduced in DOM Level 3: def getInterface(feature): ''' returns Node Args: feature: DOMString ''' # Introduced in DOM Level 3: def setUserData(key, data, handler): ''' returns DOMObject Args: key: DOMString data: DOMObject handler: UserDataHandler ''' # Introduced in DOM Level 3: def getUserData(key): ''' returns DOMObject Args: key: DOMString ''' class NodeList: def item(index): ''' returns Node Args: index: int ''' #readonly attribute length def _get_length(): ''' returns int ''' class NamedNodeMap : def getNamedItem(name): ''' returns Node Args: name: DOMString ''' def setNamedItem(arg): ''' returns Node Args: arg: Node raises DOMException ''' def removeNamedItem(name): ''' returns Node Args: name: DOMString raises DOMException ''' def item(index): ''' returns Node Args: index: int ''' #readonly attribute length def _get_length(): ''' returns int ''' # Introduced in DOM Level 2: def getNamedItemNS(namespaceURI, localName): ''' returns Node Args: namespaceURI: DOMString localName: DOMString ''' # Introduced in DOM Level 2: def setNamedItemNS(arg): ''' returns Node Args: arg: Node raises DOMException ''' # Introduced in DOM Level 2: def removeNamedItemNS(namespaceURI, localName): ''' returns Node Args: namespaceURI: DOMString localName: DOMString raises DOMException ''' class CharacterData(Node): #attribute data def _get_data(): ''' returns DOMString raises DOMException ''' def _set_data(data): ''' returns None Args: data: DOMString raises DOMException ''' #readonly attribute length def _get_length(): ''' returns int ''' def substringData(offset, count): ''' returns DOMString Args: offset: int count: int raises DOMException ''' def appendData(arg): ''' returns None Args: arg: DOMString raises DOMException ''' def insertData(offset, arg): ''' returns None Args: offset: int arg: DOMString raises DOMException ''' def deleteData(offset, count): ''' returns None Args: offset: int count: int raises DOMException ''' def replaceData(offset, count, arg): ''' returns None Args: offset: int count: int arg: DOMString raises DOMException ''' class Attr(Node): #readonly attribute name def _get_name(): ''' returns DOMString ''' #readonly attribute specified def _get_specified(): ''' returns boolean ''' #attribute value def _get_value(): ''' returns DOMString ''' def _set_value(value): ''' returns None Args: value: DOMString raises DOMException ''' # Introduced in DOM Level 2: #readonly attribute ownerElement def _get_ownerElement(): ''' returns Element ''' class Element(Node): #readonly attribute tagName def _get_tagName(): ''' returns DOMString ''' def getAttribute(name): ''' returns DOMString Args: name: DOMString ''' def setAttribute(name, value): ''' returns None Args: name: DOMString value: DOMString raises DOMException ''' def removeAttribute(name): ''' returns None Args: name: DOMString raises DOMException ''' def getAttributeNode(name): ''' returns Attr Args: name: DOMString ''' def setAttributeNode(newAttr): ''' returns Attr Args: newAttr: Attr raises DOMException ''' def removeAttributeNode(oldAttr): ''' returns Attr Args: oldAttr: Attr raises DOMException ''' def getElementsByTagName(name): ''' returns NodeList Args: name: DOMString ''' # Introduced in DOM Level 2: def getAttributeNS(namespaceURI, localName): ''' returns DOMString Args: namespaceURI: DOMString localName: DOMString ''' # Introduced in DOM Level 2: def setAttributeNS(namespaceURI, qualifiedName, value): ''' returns None Args: namespaceURI: DOMString qualifiedName: DOMString value: DOMString raises DOMException ''' # Introduced in DOM Level 2: def removeAttributeNS(namespaceURI, localName): ''' returns None Args: namespaceURI: DOMString localName: DOMString raises DOMException ''' # Introduced in DOM Level 2: def getAttributeNodeNS(namespaceURI, localName): ''' returns Attr Args: namespaceURI: DOMString localName: DOMString ''' # Introduced in DOM Level 2: def setAttributeNodeNS(newAttr): ''' returns Attr Args: newAttr: Attr raises DOMException ''' # Introduced in DOM Level 2: def getElementsByTagNameNS(namespaceURI, localName): ''' returns NodeList Args: namespaceURI: DOMString localName: DOMString ''' # Introduced in DOM Level 2: def hasAttribute(name): ''' returns boolean Args: name: DOMString ''' # Introduced in DOM Level 2: def hasAttributeNS(namespaceURI, localName): ''' returns boolean Args: namespaceURI: DOMString localName: DOMString ''' class Text(CharacterData): def splitText(offset): ''' returns Text Args: offset: int raises DOMException ''' # Introduced in DOM Level 3: #readonly attribute isWhitespaceInElementContent def _get_isWhiteSpaceInElementContent(): ''' returns boolean ''' # Introduced in DOM Level 3: #readonly attribute wholeText def _get_wholeText(): ''' returns DOMString ''' # Introduced in DOM Level 3: def replaceWholeText(content): ''' returns Text Args: content: DOMString raises DOMException ''' class Comment(CharacterData): pass class UserDataHandler : # OperationType CLONED = 1 IMPORTED = 2 DELETED = 3 def handle(operation, key, data, src, dst): ''' returns None Args: operation: int key: DOMString data: DOMObject src: Node dst: Node ''' class DOMError : SEVERITY_WARNING = 0 SEVERITY_ERROR = 1 SEVERITY_FATAL_ERROR = 2 #readonly attribute severity def _get_severity(): ''' returns int ''' #readonly attribute message def _get_message(): ''' returns DOMString ''' #readonly attribute exception def _get_exception(): ''' returns Object ''' #readonly attribute location def _get_location(): ''' returns DOMLocator ''' class DOMErrorHandler : def handleError(error): ''' returns boolean Args: error: DOMError ''' class DOMLocator : #readonly attribute lineNumber def _get_lineNumber(): ''' returns int ''' #readonly attribute columnNumber def _get_columnNumber(): ''' returns int ''' #readonly attribute offset def _get_offset(): ''' returns int ''' #readonly attribute errorNode def _get_errorNode(): ''' returns Node ''' #readonly attribute uri def _get_uri(): ''' returns DOMString ''' class CDATASection(Text): pass class DocumentType(Node): #readonly attribute name def _get_name(): ''' returns DOMString ''' #readonly attribute entities def _get_entities(): ''' returns NamedNodeMap ''' #readonly attribute notations def _get_notations(): ''' returns NamedNodeMap ''' # Introduced in DOM Level 2: #readonly attribute publicId def _get_publicId(): ''' returns DOMString ''' # Introduced in DOM Level 2: #readonly attribute systemId def _get_systemId(): ''' returns DOMString ''' # Introduced in DOM Level 2: #readonly attribute internalSubset def _get_internalSubset(): ''' returns DOMString ''' class Notation(Node): #readonly attribute publicId def _get_publicId(): ''' returns DOMString ''' #readonly attribute systemId def _get_systemId(): ''' returns DOMString ''' class Entity(Node): #readonly attribute publicId def _get_publicId(): ''' returns DOMString ''' #readonly attribute systemId def _get_systemId(): ''' returns DOMString ''' #readonly attribute notationName def _get_notationName(): ''' returns DOMString ''' # Introduced in DOM Level 3: #attribute actualEncoding def _get_actualEncoding(): ''' returns DOMString ''' def _set_actualEncoding(actualEncoding): ''' returns None Args: actualEncoding: DOMString ''' # Introduced in DOM Level 3: #attribute encoding def _get_encoding(): ''' returns DOMString ''' def _set_encoding(encoding): ''' returns None Args: encoding: DOMString ''' # Introduced in DOM Level 3: #attribute version def _get_version(): ''' returns DOMString ''' def _set_version(version): ''' returns None Args: version: DOMString ''' class EntityReference(Node): pass class ProcessingInstruction(Node): #readonly attribute target def _get_target(): ''' returns DOMString ''' #attribute DOMString data def _get_data(): ''' returns DOMString ''' def _set_data(data): ''' returns None Args: data: DOMString raises DOMException ''' class DocumentFragment(Node ): pass class Document(Node): # Modified in DOM Level 3: #readonly attribute doctype def _get_doctype(): ''' returns DocumentType ''' #readonly attribute implementation def _get_implementation(): ''' returns DOMImplementation ''' #readonly attribute documentElement def _get_documentElement(): ''' returns Element ''' def createElement(tagName): ''' returns Element Args: tagName: DOMString raises DOMException ''' def createDocumentFragment(): ''' returns DocumentFragment ''' def createTextNode(data): ''' returns Text Args: data: DOMString ''' def createComment(data): ''' returns Comment Args: data: DOMString ''' def createCDATASection(data): ''' returns CDATASection Args: data: DOMString raises DOMException ''' def createProcessingInstruction(target, data): ''' returns ProcessingInstruction Args: target: DOMString data: DOMString raises DOMException ''' def createAttribute(name): ''' returns Attr Args: name: DOMString raises DOMException ''' def createEntityReference(name): ''' returns EntityReference Args: name: DOMString raises DOMException ''' def getElementsByTagName(tagname): ''' returns NodeList Args: tagname: DOMString ''' # Introduced in DOM Level 2: def importNode(importedNode, deep): ''' returns Node Args: importedNode: Node deep: boolean raises DOMException ''' # Introduced in DOM Level 2: def createElementNS(namespaceURI, qualifiedName): ''' returns Element Args: namespaceURI: DOMString qualifiedName: DOMString raises DOMException ''' # Introduced in DOM Level 2: def createAttributeNS(namespaceURI, qualifiedName): ''' returns Attr Args: namespaceURI: DOMString qualifiedName: DOMString raises DOMException ''' # Introduced in DOM Level 2: def getElementsByTagNameNS(namespaceURI, localName): ''' returns NodeList Args: namespaceURI: DOMString localName: DOMString ''' # Introduced in DOM Level 2: def getElementById(elementId): ''' returns Element Args: elementId: DOMString ''' # Introduced in DOM Level 3: #attribute actualEncoding def _get_actualEncoding(): ''' returns DOMString ''' def _set_actualEncoding(actualEncoding): ''' returns None Args: actualEncoding: DOMString ''' # Introduced in DOM Level 3: #attribute encoding def _get_encoding(): ''' returns DOMString ''' def _set_encoding(encoding): ''' returns None Args: encoding: DOMString ''' # Introduced in DOM Level 3: #attribute standalone def _get_standalone(): ''' returns boolean ''' def _set_standalone(standalone): ''' returns None Args: standalone: boolean ''' # Introduced in DOM Level 3: #attribute strictErrorChecking def _get_strictErrorChecking(): ''' returns boolean ''' def _set_strictErrorChecking(strictErrorChecking): ''' returns None Args: strictErrorChecking: boolean ''' # Introduced in DOM Level 3: #attribute DOMString version def _get_version(): ''' returns DOMString ''' def _set_version(version): ''' returns None Args: version: DOMString ''' # Introduced in DOM Level 3: def adoptNode(source): ''' returns Node Args: source: Node raises DOMException ''' # Introduced in DOM Level 3: def setBaseURI(baseURI): ''' returns None Args: baseURI: DOMString raises DOMException ''' ---------------- end dom3.py -------------------------------- --Dethe Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) Living Code Weblog (http://livingcode.ca) From dethe at burningtiger.com Thu Nov 1 13:12:59 2001 From: dethe at burningtiger.com (Dethe Elza) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Status report References: <20011031234740.A766@vet.uu.nl> Message-ID: <3BE190AB.4080209@burningtiger.com> I think adding a UUID to nodes is a small price to pay for persistence. There is an mxUID type available from eGenix: http://www.lemburg.com/files/python/ There's also a Uuid.py in the 4SuiteServer package: http://www.4suite.org UUIDs (Universally Unique IDentifiers) or GUIDs (Globally Unique IDentifiers) are generally used as pointers to persistent data. They are used in various persistence systems, DCE, and DCOM. There's a fuller discussion of the issues and how to generate the beasts at: http://www1.ics.uci.edu/pub/ietf/webdav/uuid-guid/draft-leach-uuids-guids-01.txt --Dethe -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) Living Code Weblog (http://livingcode.ca) From faassen at vet.uu.nl Thu Nov 1 14:55:06 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XMLWidgets woohoo! Message-ID: <20011101205505.A4724@vet.uu.nl> Hi there, I've just made the core of XMLWidgets the ParsedXML Generation, and it works! :) Not that it is done at all yet, but I'm happy anyway. In fact as far as I can see it works better than the old XMLWidgets for XMLDocument ever did, and probably takes less processor time! Lots of features are still missing though, such as caching, supporting editing, and so on. An important first step I need to take to implement these features is the whole URL to node issue. For rendering documents however I have a basic demo running. Just wanted to share the good news, even though many of you probably have no clue what XMLWidgets would be good for in the first place. An old description of XMLWidgets is here: http://www.zope.org/Wikis/zope-xml/History%20and%20design%20of%20XMLWidgets If you don't understand, don't worry; Jim Fulton didn't understand either, and only got it when I actually demonstrated them to him this year at the Python conference. :) XMLWidgets is basically a bit of magic. It is now is starting to look like actual consistent transparent magic, which is the only good magic in software. What the magic does is enable you to associate a Zope object (say, a folder with methods) with a DOM node on the fly. Depending on what the DOM node is or even its context (say, a 'p' node in a 'section' node), you can associate different objects (widgets) with different methods (which may have the same signature though). In the end, this allows you to dynamically associate new methods to DOM nodes. So, you can associate a 'render' method to each DOM node, depending on what it is. For 'p' nodes you add one render method, for 'section' nodes you add another. This way you can just call render on each node and have it do the right thing. This allows you to build renderers, but also more advanced applications, such as through the web semi-WYSIWYG XML editors. Okay, did I lose everyone? :) Regards, Martijn From kra at monkey.org Thu Nov 1 20:11:41 2001 From: kra at monkey.org (Karl Anderson) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Re: [Parsed-XML-Dev] keeping references to nodes In-Reply-To: Martijn Faassen's message of "Sat, 27 Oct 2001 02:22:44 +0200" References: <20011027022244.A15657@vet.uu.nl> Message-ID: Martijn Faassen writes: > What I want to have is an ability to keep a reference to a unique > node in a document, without using a reference to the node itself > directly. > One simple way is to simply keep a reference to the node directly. > Unfortunately that seems hard to do for sessions and would cause a lot > of growth of the ZODB if references are kept there. Nodes may never > get garbage collected. > > Another way is to give each node that is created a unique id. For that > we'd need to change the DOM in some places and we'll have to carry the > unique id around, but that'd certainly be possible. Problem with either of these is that the entire subtree is replaced on a parse. References to the old subtree are worthless, and there isn't a reliable way to make sure that the new nodes get the same ID as the old nodes. If you're using XML IDs the problem is solved, of course, and there are DOM methods to work with that. I remember before that you were saying that you didn't want to have to change the XML source to support this feature, though, and you want it to work for XML without IDs. That's a valid concern, but I dunno, your problem is really a drawback of XML. Unless there is an ID attribute expressed in XML, there just isn't a way to identify an XML node other than by saying how to traverse to it, so the DOM can't express this either. > Yet another way would be to exploit some properties of the ZODB to get > a unique id to the node object. Since nodes aren't persistent objects > directly, I guess that won't work, right? yup, they're just attributes of the single persistent object, the document. -- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/ From kra at monkey.org Thu Nov 1 20:21:40 2001 From: kra at monkey.org (Karl Anderson) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Status report In-Reply-To: "'Martijn Faassen'"'s message of "Wed, 31 Oct 2001 23:47:40 +0100" References: <20011031234740.A766@vet.uu.nl> Message-ID: "'Martijn Faassen'" writes: > Perhaps we should design a form of scheme where these different types of > URLs into ParsedXML's DOM can all happily live together. IDs, child node > #s, heuristics, bookmarks, etc. Anyone have any ideas? http://www.zope.org/Wikis/DevSite/Projects/ParsedXML/URIPublishing -- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/ From webmaven at lvcm.com Thu Nov 1 22:15:41 2001 From: webmaven at lvcm.com (Michael R. Bernstein) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XMLWidgets woohoo! In-Reply-To: <20011101205505.A4724@vet.uu.nl> References: <20011101205505.A4724@vet.uu.nl> Message-ID: <1004670941.1567.79.camel@fiawol> On Thu, 2001-11-01 at 11:55, Martijn Faassen wrote: > > I've just made the core of XMLWidgets the ParsedXML Generation, and it works! :) > Not that it is done at all yet, but I'm happy anyway. > [snip] > Lots of features are still missing though, such as caching, supporting > editing, and so on. An important first step I need to take to > implement these features is the whole URL to node issue. Good luck. Please keep in mind the use case of two different users editing (or adding, or deleting) different parts of the document (different nodes). I'm beginning to suspect that some sort of generic 'tree-diff' is necessary (or at least desireable). Somehow, diff doesn't get confused by lines being added or deleted in the middle of a text, only flagging actual conflicting changes. A hypothetical 'tree-diff' needs to not be confused by nodes added, edited, or deleted in arbitrary locations in the node-tree, only flagging actual conflicting changes. I have no idea how to accomplish this. > [major snippage] > This allows you to build renderers, but also more advanced applications, > such as through the web semi-WYSIWYG XML editors. > > Okay, did I lose everyone? :) Not me. :-) Keep going, don't let us stop you. Michael Bernstein. From dethe at burningtiger.com Thu Nov 1 23:32:07 2001 From: dethe at burningtiger.com (Dethe Elza) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XMLWidgets woohoo! References: <20011101205505.A4724@vet.uu.nl> <1004670941.1567.79.camel@fiawol> Message-ID: <3BE221C7.2010501@burningtiger.com> Michael R. Bernstein wrote: > Good luck. Please keep in mind the use case of two different users > editing (or adding, or deleting) different parts of the document > (different nodes). I'm beginning to suspect that some sort of generic > 'tree-diff' is necessary (or at least desireable). IBM's alphaWorks has a TreeDiff tool for XML, but it's in Java. It might be worth a look to see how they've approached the problem, though. http://alphaworks.ibm.com/tech/xmltreediff --Dethe -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) Living Code Weblog (http://livingcode.ca) From paul at zope.com Fri Nov 2 08:07:40 2001 From: paul at zope.com (Paul Everitt) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XMLWidgets woohoo! References: <20011101205505.A4724@vet.uu.nl> <1004670941.1567.79.camel@fiawol> <3BE221C7.2010501@burningtiger.com> Message-ID: <3BE29A9C.8000601@zope.com> There's also a Python tree-diff, but it's quite slow. Takes over a minute on a medium-sized document. This, alas, is a hard problem. --Paul Dethe Elza wrote: > Michael R. Bernstein wrote: > > >> Good luck. Please keep in mind the use case of two different users >> editing (or adding, or deleting) different parts of the document >> (different nodes). I'm beginning to suspect that some sort of generic >> 'tree-diff' is necessary (or at least desireable). > > > IBM's alphaWorks has a TreeDiff tool for XML, but it's in Java. It > might be worth a look to see how they've approached the problem, though. > > http://alphaworks.ibm.com/tech/xmltreediff > > --Dethe > From kthangavelu at earthlink.net Fri Nov 2 07:00:17 2001 From: kthangavelu at earthlink.net (kapil thangavelu) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XMLWidgets woohoo! In-Reply-To: <3BE29A9C.8000601@zope.com> References: <20011101205505.A4724@vet.uu.nl> <3BE221C7.2010501@burningtiger.com> <3BE29A9C.8000601@zope.com> Message-ID: <200111021850.fA2Io3P203844@pimout4-int.prodigy.net> I think paul is referring to the one at www.logilab.org kapil On Friday 02 November 2001 05:07 am, Paul Everitt wrote: > There's also a Python tree-diff, but it's quite slow. Takes over a > minute on a medium-sized document. This, alas, is a hard problem. > > --Paul > > Dethe Elza wrote: > > Michael R. Bernstein wrote: > >> Good luck. Please keep in mind the use case of two different users > >> editing (or adding, or deleting) different parts of the document > >> (different nodes). I'm beginning to suspect that some sort of generic > >> 'tree-diff' is necessary (or at least desireable). > > > > IBM's alphaWorks has a TreeDiff tool for XML, but it's in Java. It > > might be worth a look to see how they've approached the problem, though. > > > > http://alphaworks.ibm.com/tech/xmltreediff > > > > --Dethe > > _______________________________________________ > Zope-xml mailing list > Zope-xml@zope.org > http://lists.zope.org/mailman/listinfo/zope-xml From kthangavelu at earthlink.net Fri Nov 2 08:17:28 2001 From: kthangavelu at earthlink.net (kapil thangavelu) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Any interest in a set of Zope products to support CVS-versioned, XML/XSLT-based Zope development? In-Reply-To: <3BDF66F2.2010801@arielpartners.com> References: <3BDF6241.9010509@arielpartners.com> <15327.22053.333953.296807@mcallister.cyc.com> <3BDF66F2.2010801@arielpartners.com> Message-ID: <200111022007.fA2K7Lq173442@pimout2-int.prodigy.net> On Tuesday 30 October 2001 06:50 pm, Craeg K. Strong wrote: > We looked at 4suite but it looked like it was not ready for prime time. > What do you think? did you actually try it? i think its a bit slow, but it seems to be fairly compliant, the only way to know for sure is to test it... also there is pyana.sf.net and pirxx.sf.net for python wrappers based on the apache xml project's xalan/xerces (c++ variants). cheers kapil From kra at monkey.org Fri Nov 2 23:50:05 2001 From: kra at monkey.org (Karl Anderson) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Canonical Python DOM Interface In-Reply-To: Dethe Elza's message of "Tue, 30 Oct 2001 21:19:32 -0800" References: <3BDF89E4.5010205@burningtiger.com> Message-ID: Dethe Elza writes: > In Java-land there's an official interface which the DOM must implement, > so there are certainties you can count on with all the various DOM > implementations (modulo explicitly non-standard ones such as JDOM). > > Here in Python-land, there is 4DOM, minidom, ParsedXML's DOM, pulldom, > javadom, and I'm sure I'm missing a few (maybe more than a few). > > Is there a canonical interface defined anywhere? I realize that there > is a canonical OMG IDL interface, and a canonical IDL -> Python binding, > but is that what is being used? Yeah. > And if so, does anyone have it mapped > to Python, or is there some relatively easy way to do this? I don't understand this question. DOM is defined by the IDL interface, so the Python DOM API is defined by that and the canonical IDL-Python mapping. Any Python classes that claim to provide the DOM API is claiming to provide those signatures. The link is frustratingly hard to find, at least for me: see for the mapping specification and for the IDL interfaces. > Given that, I think I can figure out a way to test a given DOM > implementation for conformance to that interface and we can get some > data on how widely the various implementations diverge from each other > (unless someone has already done that as well). Well, that's exactly what ParsedXML's test suite does. It works for *any* Python DOM implementation because it knows exactly what the API being provided is. See test_pyxmldom.py, which tests the PyXML DOM. What do you see as missing from the tester to do this? All it needs is a way to get a DOMImplementation, which isn't covered by the API, and a way to create a DOM document by parsing an XML string - but the need for thet parser is a bug in the spec, IIRC, some things can't be created via DOM calls alone. Although, IIRC, we use the parser more than absolutely necessary in the testing. What the tester really *does* need to compare DOM implementations, and to allow for more robust testing of a partial DOM implementation, is a little refactoring to make the tests less interdependent. Right now, the tests work fine for very complete DOM impelementations, but less interdependence would be allow the developer to prioritize bugs better. That's the first item in my Zope XML roadmap on the zope-xml wiki - IMHO that's the most important step for XML in Zope overall. -- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/ From dethe at burningtiger.com Sat Nov 3 00:58:14 2001 From: dethe at burningtiger.com (Dethe Elza) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Canonical Python DOM Interface References: <3BDF89E4.5010205@burningtiger.com> Message-ID: <3BE38776.3020409@burningtiger.com> Karl Anderson wrote: > I don't understand this question. DOM is defined by the IDL > interface, so the Python DOM API is defined by that and the > canonical IDL-Python mapping. Any Python classes that claim to > provide the DOM API is claiming to provide those signatures. Well, the DOM may be defined by the IDL, but I know the Java and Javascript mappings take liberties with that definition--I don't believe they are direct IDL mappings. And until I read the Python IDL mapping I found some parts of the Python DOM very confusing even though I've been doing DOM programming since before XML was made a W3C recommendation. I also think having a document which states, "Here is what Python thinks the DOM looks like," is *much* better than having the IDL and the Python mapping, which is why I took it on myself to do just that (see my earlier, loooong, post). I know I've referred to the Java and Javascript mappings at the W3 site religiously for years, so it seems like a Python version would be useful. Also useful would be a mapping of which methods are suitable for read-only and which mutate the DOM, which I worked up tonight (90 Read-only, 55 Mutate) and can post if anyone's interested. Also usefull would be a matrix of which implementations support which set of methods, especially if the sets don't exactly follow the DOM1, DOM2, DOM3 splits. I've been frustrated for a long time with Mozilla's claim to support *some* of CSS2--which parts?!? Let's get explicit here, it makes things a lot more useful if you can tell in advance what works without having to run a lot of exploratory tests or try reading the code (and while Python code is more readable than pretty much any other language I've ever had to do archeology on, it's still not my the most productive use of my time). > Well, that's exactly what ParsedXML's test suite does. It works for > *any* Python DOM implementation because it knows exactly what the API > being provided is. See test_pyxmldom.py, which tests the PyXML DOM. OK, my understanding of the ParsedXML test suite is that it tests the functions of the DOM, which is great, but first I want to know about the *existence* of the various methods in each implementation. > What the tester really *does* need to compare DOM implementations, and > to allow for more robust testing of a partial DOM implementation, is > a little refactoring to make the tests less interdependent. Right > now, the tests work fine for very complete DOM impelementations, but > less interdependence would be allow the developer to prioritize bugs > better. Maybe I should get involved and help with the refactoring, it sounds like good experience getting under the hood with Python XML. Thanks for the feedback. --Dethe -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) Living Code Weblog (http://livingcode.ca) From webmaven at lvcm.com Sat Nov 3 03:34:46 2001 From: webmaven at lvcm.com (Michael R. Bernstein) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XMLWidgets woohoo! In-Reply-To: <3BE29A9C.8000601@zope.com> References: <20011101205505.A4724@vet.uu.nl> <1004670941.1567.79.camel@fiawol> <3BE221C7.2010501@burningtiger.com> <3BE29A9C.8000601@zope.com> Message-ID: <1004776487.733.266.camel@fiawol> On Fri, 2001-11-02 at 05:07, Paul Everitt wrote: > > There's also a Python tree-diff, but it's quite slow. Takes over a > minute on a medium-sized document. What is 'medium sized' in this context? Does the time scale with the number of nodes, the depth of the tree, or some other factor? Michael. From kra at monkey.org Sat Nov 3 16:02:16 2001 From: kra at monkey.org (Karl Anderson) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Canonical Python DOM Interface In-Reply-To: Dethe Elza's message of "Fri, 02 Nov 2001 21:58:14 -0800" References: <3BDF89E4.5010205@burningtiger.com> <3BE38776.3020409@burningtiger.com> Message-ID: Dethe Elza writes: > > Well, that's exactly what ParsedXML's test suite does. It works for > > *any* Python DOM implementation because it knows exactly what the API > > being provided is. See test_pyxmldom.py, which tests the PyXML DOM. > > OK, my understanding of the ParsedXML test suite is that it tests the > functions of the DOM, which is great, but first I want to know about the > *existence* of the various methods in each implementation. Oh, I finally get what you were saying, I wasn't really adding anything new, was I :) The ParsedXML tester should provide the same information regarding the method signatures - just look for raises of TypeError and AttributeError in the failure output, right? - but it's valuable enough to have a clear, separate test for that, given how I whine about the interdependence of the tester getting in the way of testing priorities! > > I don't understand this question. DOM is defined by the IDL > > interface, so the Python DOM API is defined by that and the > > canonical IDL-Python mapping. Any Python classes that claim to > > provide the DOM API is claiming to provide those signatures. > > Well, the DOM may be defined by the IDL, but I know the Java and > Javascript mappings take liberties with that definition--I don't believe > they are direct IDL mappings. Nuts to that! Working with the DOM has turned me into a standards wonk. The DOM is low-level, chances are that an XSLT or XPath processor is going to exercise some corner of the API. Bugs are bugs, but an implementation that strays from the spec, not to mention the method signatures, without clearly documenting the difference suffers from a pretty big documentation bug. Not that your tester is any less important because of that, but it *should* only be necessary to use it to verify, not discover! Oh well, it's a tough world ;) -- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/ From dethe at burningtiger.com Sat Nov 3 16:55:24 2001 From: dethe at burningtiger.com (Dethe Elza) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Canonical Python DOM Interface References: <3BDF89E4.5010205@burningtiger.com> <3BE38776.3020409@burningtiger.com> Message-ID: <3BE467CC.8060505@burningtiger.com> Karl Anderson wrote: > > Oh, I finally get what you were saying, I wasn't really adding > anything new, was I :) The ParsedXML tester should provide the same > information regarding the method signatures - just look for raises of > TypeError and AttributeError in the failure output, right? - but it's > valuable enough to have a clear, separate test for that, given how I > whine about the interdependence of the tester getting in the way of > testing priorities! So you're saying that maybe I'm not crazy? Whew, that's a relief! Even if it's not true %-) > Nuts to that! Working with the DOM has turned me into a standards > wonk. The DOM is low-level, chances are that an XSLT or XPath > processor is going to exercise some corner of the API. Bugs are bugs, > but an implementation that strays from the spec, not to mention the > method signatures, without clearly documenting the difference suffers > from a pretty big documentation bug. Not that your tester is any less > important because of that, but it *should* only be necessary to use it > to verify, not discover! Oh well, it's a tough world ;) The thing is, both Javascript and Java have well-defined DOM APIs, so it's not a problem necessarily that they don't follow the IDL specification strictly--as long as they follow their stated APIs strictly. What I couldn't find was the "official" Python bindings to the DOM, in case of any difference between that mythical beast and a pure application of the IDL. I was vaguely aware that the W3C DOM page has a place to register other bindings than Javascript and Java, and thought we could register the Python one there once it was documented (I couldn't find it documented in the Python library, apparently I was looking in the wrong place). Well, I finally found the DOM page[1] and Python *is* registered[2], so there *is* an "official" Python binding, and it's *not* a straight mapping of the IDL[3] as I read the IDL mapping[4], which would explain some of the inconsistencies I've stumbled across trying to work with the DOM, if some people support the official binding and some support the IDL mapping (of course, it's possible to support both). So, now I need to condense the API into one document and incorporate it in my mapping of the IDL somehow, then look into the test cases and see what we've got and where I can help out. The plot thickens (or was that the oatmeal I had for breakfast?). Onward! --Dethe [1] http://www.w3.org/DOM/Bindings [2] http://www.python.org/doc/current/lib/module-xml.dom.html [3] http://www.w3.org/TR/2001/WD-DOM-Level-3-Core-20010913/idl-definitions.html [4] http://cgi.omg.org/cgi-bin/doc?ptc/00-04-08 -- Dethe Elza (delza@burningtiger.com) Chief Mad Scientist Burning Tiger Technologies (http://burningtiger.com) Living Code Weblog (http://livingcode.ca) From mj at zope.com Mon Nov 5 10:49:43 2001 From: mj at zope.com (Martijn Pieters) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Re: FW: Zope TAL/ParsedXML/ZTUtils etc In-Reply-To: References: Message-ID: <20011105104939.O29135@zope.com> On Mon, Nov 05, 2001 at 01:27:09PM +0000, Robert Neuschul wrote: > I sent the following to Karl; he autoresponded that I need to talk to > you instead. > You might want to suggest to him that his autoresponder be altered so as > to actually include your email address. I'll pass that on to the sysop. Thanks! > Hi Karl > > For my sins, I'm trying to get this combo to run on a W32 platform - > specifically a W2000 Server. It appears to work fine on our Linux > boxen; yes I know I should use the Linux, but there are practical > reasons why I need this on W2K. > > I'm running what I believe is the latest W32 Zope build [alongside the > latest Apache Win], both were downloaded and installed about 5 weeks > ago. I also have Visual Studio C/C++ installed for reasons I can't > really justify, but which gives me a workable C compiler on this > platform. > > This Zope of course uses Python 2.1. Zope itself works fine. > > I am hitting a specific problem: Parsed XML appears to be looking for a > specific windows dll - python1.5.dll. I have combed all of the > makefiles and python scripts that come with the three tools, changed > all references from python1.5 to python, and recompiled everything. > I've also looked at just about everything else I can think of, looking > for a reference that specifies this particular dll. So far I cannot > find it. I'm still getting the same error message on Zope startup. Are you using the ParsedXML binary? it was compiled specifically with Python 1.5.2. You'll either have to recompile Expat with Python 2.1, or just use the pyexpat that comes with Python 2.1; I believe that version is up-to-date enough to make ParsedXML happy. Removining all .dll files in the ParsedXML distribution *should* be enough. If you *do* compile the extension, could we maybe recruit you to help out with a windows build for Python 2.1 of the next version of ParsedXML? Martijn Faassen is still looking for a way to create the binaries. > I need help - or at least the ability to discuss this with others who > might be trying the same thing. I'm obviously missing something very > obvious. > > Can you please suggest a] where to ask this question publicly and b] > possibly give me a hint about where I'm going wrong or what I should be > looking at? The best place to ask about this is the either the Parsed-XML-Dev@zope.org or zope-xml@zope.org mailinglists. I CC-ed the latter. More info about the lists can be found at: http://www.zope.org/Resources/MailingLists/ -- Martijn Pieters | Software Engineer mailto:mj@zope.com | Zope Corporation http://www.zope.com/ | Creators of Zope http://www.zope.org/ --------------------------------------------- From robert at imagine.co.uk Mon Nov 5 13:04:30 2001 From: robert at imagine.co.uk (Robert Neuschul) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Re: Zope TAL/ParsedXML/ZTUtils etc In-Reply-To: <20011105104939.O29135@zope.com> References: <20011105104939.O29135@zope.com> Message-ID: Martijn In article <20011105104939.O29135@zope.com>, Martijn Pieters wrote: > Are you using the ParsedXML binary? it was compiled specifically with Python > 1.5.2. You'll either have to recompile Expat with Python 2.1, or just use > the pyexpat that comes with Python 2.1; I believe that version is up-to-date > enough to make ParsedXML happy. Removining all .dll files in the ParsedXML > distribution *should* be enough. I started with the binary; when that wasn't very happy I trawled the source, removed all refs to Python 1.5 and then tried a fresh build/install. That didn't make a lot of difference, but it's so long since I did any serious program coding that, frankly, I'm actually less use than a complete newbie. I'll backtrack to a native install and remove/replace dll's as you suggest. > If you *do* compile the extension, could we maybe recruit you to help out > with a windows build for Python 2.1 of the next version of ParsedXML? > Martijn Faassen is still looking for a way to create the binaries. You're welcome to try recruiting me :-) I can't promise the results will be worth having though .... however almost all of our work is W2K/XP so I'm trying to work my way through the various bits of Zope code seeing how much I can get working and teaching myself Zope/Python at the same time, in the hope that I can migrate our teams/clients/sites onto a common core architecture sometime early next year. CMF and TAL/PXML et al seem to be a very promising and productive set of tools when one has our kind of customer. > The best place to ask about this is the either the Parsed-XML-Dev@zope.org > or zope-xml@zope.org mailinglists. I CC-ed the latter. More info about the > lists can be found at: > > http://www.zope.org/Resources/MailingLists/ That's brilliant. Thanks. Robert Neuschul. From faassen at vet.uu.nl Tue Nov 6 08:10:33 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Re: FW: Zope TAL/ParsedXML/ZTUtils etc In-Reply-To: <20011105104939.O29135@zope.com> References: <20011105104939.O29135@zope.com> Message-ID: <20011106141033.A4603@vet.uu.nl> Martijn Pieters wrote: [snip] > Are you using the ParsedXML binary? it was compiled specifically with Python > 1.5.2. You'll either have to recompile Expat with Python 2.1, or just use > the pyexpat that comes with Python 2.1; I believe that version is up-to-date > enough to make ParsedXML happy. Removining all .dll files in the ParsedXML > distribution *should* be enough. I think you also need to change ExpatBuilder to import pyexpat from Python instead of ParsedXML's version. > If you *do* compile the extension, could we maybe recruit you to help out > with a windows build for Python 2.1 of the next version of ParsedXML? > Martijn Faassen is still looking for a way to create the binaries. Right, I'd like that. :) Regards, Martijn From faassen at vet.uu.nl Sat Nov 10 12:40:46 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] status update Message-ID: <20011110184046.A20621@vet.uu.nl> Hi there, High time for another status update. Still no ParsedXML release, though the current CVS version is in fact fairly releasable, but for some pyexpat fixes I need to evaluate. I'll see about doing a source release first, and then I'm going to whine about Windows binary releases (both for Zope 2.3/Python 1.5.2 and for zope 2.4/Python 2.1); we already had a volunteer to help compiling so that shouldn't be too big a problem, hopefully. Other developments: * XMLWidgets now works enough to render stuff, as already reported. * lots of thinking about 'robust links' to DOM nodes, and some implementation of it. Basically there are two conflicting requirements and I don't see how to reconcile them. Luckily that doesn't seem to be necessary either. One requirement is for annotations and in general hyperlinks into an XML document. One would to be able to link to a particular section of content in an XML document. If the XML document changes, for instance in a reparse, the link should still work. If the document changes to some extend, the link should still work. Eventually of course under too many changes the link will break, but we'd like to avoid that as long as possible. Of course if one can change the document by adding unique ids, this isn't a problem, but frequently we can't change the document. After some web searches, I found an interesting paper: http://www9.org/w9cdrom/312/312.html describing a heuristic technique that can accomplish this. I've done a prototype implementation of part of what is described in the paper, and though it needs work and a lot of tuning, the results are hopeful. The other requrement however is quite different, and robust hyperlinks are too unreliable to fulfill it; XMLWidgets needs a way to construct a hyperlink to a node, and then to a certain operation on that node. For instance: http://foobar.com/mydocument/0/1/3/2/view would call the 'view' operation on node 0/1/3/2 of the document. Here I've used the node addressing scheme as currently defined by ParsedXML, which simply goes by childnode index. This will work for this particular operation, 'view', but will be quite brittle if the document can change, for instance due to node insertions and node deletions. Something I already started implementating, and I've pushed that a bit further, are document-unique element id. Each element will get a unique id and this can be used for addressing as well: http://foobar.com/mydocument/e0/e5/e2/view though non elements are still indicated by child index and child indexes continue to work: http://foobar.com/mydocument/e0/2/e3 Because the element ids are unique, this is far less brittle. If the node exists, the url will work even after insertions and deleting. It won't work after more radical structure rearranging (though one could still get hold of it again by looking for the id in the document), but that's okay for much of my purposes. And at least it won't return the *wrong* node ever. Next up: I think we need a way to let all these addressing schemes coexist, and the ability to add more. XMLWidgets for instance also will need to hook in its own addressing scheme, I think, so that the methods will be called on the widget wrapper and not on the normal manageablewrapper. I'm still trying to work out what this would look like. Some ideas: Path element: document/bychild/0/1/2 document/element_id/e0/1 document/widgets/e1/e2 URL argument: document?bychild=/0/1/2 document?element_id=/e0/e3 document?widgets=/e0/e3 Or even something I read about today, URI arguments: document;scheme=bychild/0/1/2 document;scheme=element_id/e0/e3 document;scheme=widgets/e0/e3 Here's Jim Fulton on the latter: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ExplicitNamespaceControlInURLs Though I think we may go with one of the former now and implement the latter as soon as Zope's ready for them. Regards, Martijn From faassen at vet.uu.nl Mon Nov 19 14:28:11 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Status update Message-ID: <20011119202811.A21597@vet.uu.nl> Hi there, As you can see, I've released ParsedXML 1.2.1 yesterday. This includes my DOM access speedups and some parser upgrades. Also the unit tests are cleaned up some. The next step for ParsedXML is making Windows support easier (by providing a binary or perhaps by falling back to Python's pyexpat), and element ids to construct more stable paths to nodes. On the path to nodes topic I've developed a general framework for different node path schemes. I mean to provide hooks in ParsedXML so that other URL to node schemes can be easily added. So far I've implemented the original child node index style of paths (0/3/2), the element id version (if element ids are available (e1/e17/2), and robust linking (won't give an example here as they're rather long). Robust linking remains the most untested but it should be pretty powerful; the robust links can survive changes to the document (and reparses). They'd be particularly useful for non-intrusive annotations. Regards, Martijn From nico at tekNico.net Tue Nov 20 12:51:03 2001 From: nico at tekNico.net (Nicola Larosa) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Re: Status update References: Message-ID: <3BFA9807.7000609@tekNico.net> > The next step for ParsedXML is making Windows support easier (by providing > a binary or perhaps by falling back to Python's pyexpat), and element ids > to construct more stable paths to nodes. In the Python 2.0 binary distribution for Windows there is a file DLLs\pyexpat.pyd Accordingly, in the Zope 2.4 binary distribution for Windows there is a file bin\DLLs\pyexpat.pyd Now, while in the Python 2.1.1 binary distribution for Linux there is a file lib/python2.1/lib-dynload/pyexpat.so in the Zope 2.4 binary distribution for Linux there is no such file! Is there any reason for this silent suppression? -- "Mozilla will be around long after nobody can remember just quite what Internet Explorer actually used to be." AirLace on Slashdot Nicola Larosa - nico@tekNico.net From faassen at vet.uu.nl Tue Nov 20 14:43:01 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Re: Status update In-Reply-To: <3BFA9807.7000609@tekNico.net> References: <3BFA9807.7000609@tekNico.net> Message-ID: <20011120204301.A26487@vet.uu.nl> Nicola Larosa wrote: > >The next step for ParsedXML is making Windows support easier (by providing > >a binary or perhaps by falling back to Python's pyexpat), and element ids > >to construct more stable paths to nodes. > > In the Python 2.0 binary distribution for Windows there is a file > > DLLs\pyexpat.pyd > > Accordingly, in the Zope 2.4 binary distribution for Windows there is a file > > bin\DLLs\pyexpat.pyd > > Now, while in the Python 2.1.1 binary distribution for Linux there is a file > > lib/python2.1/lib-dynload/pyexpat.so > > in the Zope 2.4 binary distribution for Linux there is no such file! > > Is there any reason for this silent suppression? Weird. I'll pass this along to zope-coders. Regards, Martijn From webmaven at lvcm.com Tue Nov 20 17:28:49 2001 From: webmaven at lvcm.com (Michael R. Bernstein) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Status update In-Reply-To: <20011119202811.A21597@vet.uu.nl> References: <20011119202811.A21597@vet.uu.nl> Message-ID: <1006295330.8824.24.camel@fiawol> On Mon, 2001-11-19 at 11:28, Martijn Faassen wrote: > > On the path to nodes topic I've developed a general framework for > different node path schemes. I mean to provide hooks in ParsedXML so > that other URL to node schemes can be easily added. So far I've implemented > the original child node index style of paths (0/3/2), the element id version > (if element ids are available (e1/e17/2), and robust linking (won't give > an example here as they're rather long). Robust linking remains the most > untested but it should be pretty powerful; the robust links can > survive changes to the document (and reparses). They'd be particularly useful > for non-intrusive annotations. Which (Element IDs or Robust Links) would you recommend for the following use cases: Use Case 1: ---------- User A and User B are both viewing the same XML document using a web-based viewer/editor. User A clicks a 'delete' icon in a rendered node, or adds a new node, or moves a node, thereby altering the structure of the document. User B, who has the old version of the document rendered in her browser, edits a different node to change it's contents or attributes. I want the server to apply User B's changes to the correct node, even though the structure of the document is different. Use Case 2: ---------- Same two users, same document. This time User B's edits are on a node that User A has moved. The edit should succeed on the correct node. Use Case 3: ---------- Same two users, same document. This time User B's edit is on a node that User A has either deleted or edited first. The server should be able to issue a warning that "The version of this document that you are editing is not the most recent one", just like CVS does. So, which would be better for these use cases? Element IDs or Robust Links? Michael. From faassen at vet.uu.nl Wed Nov 21 13:42:26 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Status update In-Reply-To: <1006295330.8824.24.camel@fiawol> References: <20011119202811.A21597@vet.uu.nl> <1006295330.8824.24.camel@fiawol> Message-ID: <20011121194226.A30396@vet.uu.nl> Michael R. Bernstein wrote: > On Mon, 2001-11-19 at 11:28, Martijn Faassen wrote: > > On the path to nodes topic I've developed a general framework for > > different node path schemes. I mean to provide hooks in ParsedXML so > > that other URL to node schemes can be easily added. So far I've implemented > > the original child node index style of paths (0/3/2), the element id version > > (if element ids are available (e1/e17/2), and robust linking (won't give > > an example here as they're rather long). Robust linking remains the most > > untested but it should be pretty powerful; the robust links can > > survive changes to the document (and reparses). They'd be particularly useful > > for non-intrusive annotations. > > Which (Element IDs or Robust Links) would you recommend for the > following use cases: > > Use Case 1: > ---------- > User A and User B are both viewing the same XML document using a > web-based viewer/editor. > > User A clicks a 'delete' icon in a rendered node, or adds a new node, or > moves a node, thereby altering the structure of the document. > > User B, who has the old version of the document rendered in her browser, > edits a different node to change it's contents or attributes. > > I want the server to apply User B's changes to the correct node, even > though the structure of the document is different. For anything involving editors, unless they don't change the structure too drastically, I want something like element ids or at least some certain way to know that the node I get from the path, if I get any at all, is the right node. I shouldn't get the *wrong* node as otherwise you'd be editing in the wrong place. > Use Case 2: > ---------- > Same two users, same document. This time User B's edits are on a node > that User A has moved. The edit should succeed on the correct node. That should still work with element ids is the move is simply in the list of siblings. If it's to another section of the document, then element ids won't be able to find them (except with an exhaustive search). It depends on what kind of edits.. Anyway, two users same document is a case I'm just not even considering yet. :) > Use Case 3: > ---------- > Same two users, same document. This time User B's edit is on a node that > User A has either deleted or edited first. The server should be able to > issue a warning that "The version of this document that you are editing > is not the most recent one", just like CVS does. > > So, which would be better for these use cases? Element IDs or Robust > Links? I think Element IDs, or just XML IDs if one is allowed to alter the XML document (even better if they are at least indexed somehow so you can find them quickly). Element IDs will fail if the document is reparsed, or if the structure changes too much. Robust Paths are better for long-standing annotations. I want to annotate a node by linking something to it. The node may move quite a distance but there should still be a reasonable possibility the link to it persists. Of course changing the document and adding in an ID is even better, but frequently one doesn't want to do that. So that is the use case for robust paths. Btw, I ran into some snags trying to hook my Python code (which does quite a bit with URLs, obviously) smoothly into Zope. Need to ponder it over a bit more. Regards, Martijn From trygvel at hotmail.com Fri Nov 23 01:01:19 2001 From: trygvel at hotmail.com (Trygve Lorentzen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Documentation??? Message-ID: An HTML attachment was scrubbed... URL: http://mail.zope.org/pipermail/zope-xml/attachments/20011123/77ace044/attachment.html From faassen at vet.uu.nl Sat Nov 24 12:31:14 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Documentation??? In-Reply-To: References: Message-ID: <20011124183114.A7561@vet.uu.nl> Trygve Lorentzen wrote: [hm, this was HTML mail, so it was rather annoying to open it to reply..] > Is there any documentation at all for parsedxml? Only minimal documentation in the distribution right now. I should create some help screens and such. > I'm sure it's a good product, it's just that I don't have a clue how to > use it... It follows the W3C DOM specification (level 2, mostly). So, if you go to http://www.w3.org and read the DOM spec there (which isn't that hard to read, though it's not as easy to implement :), you get a pretty good picture of what you can do with ParsedXML programmatically. > I have imported/added an XML doc into zope and can browse the parse tree, > but what do I do from there? You can manipulate the tree programmatically in Python or DTML or ZPT by calling the right DOM methods on the right nodes. You can also let your own code be acquired by the nodes, so you can call your code on a node directly: doc.documentElement.childNodes[1].mycode() > I wan't to create a simple addressbook app with XML as backend storage > and need to be able to access the nodes through dtml or python. > Preferably dtml since I am not very familiar with python (yet). You're going to need some basic Python knowledge in order to use the DOM API, I'm afraid. You can use this Python from DTML in expr=".." bits, however. For instance: would create a new element called 'Foo' at the end of the document. (if your document has the id 'doc'). > I have look for documentation for hours without finding anything to > help me get started. Can't find much interesting in the README files > that came with the binary distribution 2.4.3 either. We do need to improve this, sorry. Any donations for help text are always welcome. :) > I also have a problem working with non ASCII-7 (norwegian) characters > in the XML. They import fine with encoding = "iso-8859-1" but when I > try to edit them, I get a parse error telling me that there is a wrong > character encoding. I am running the binary dist of zope v.2.4.3 with > python 2.1.1 on a debian 2.2 box. Hm, ParsedXML needs more help with character encodings. I myself know very little about these, I'm afraid... Anyone can help? Regards, Martijn From cnd at ecn.purdue.edu Sun Nov 25 17:31:34 2001 From: cnd at ecn.purdue.edu (Christopher N. Deckard) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Documentation??? In-Reply-To: References: Message-ID: <1006727494.2628.0.camel@moonchild.globalfoo.net> Trygve, I feel your pain. I went through the same thing. As someone else recommended, looking at the DOM spec from the w3c is how I figured out how to use it all. There are some examples in DTML which you can import, but they don't help much when it comes to actually using it in Python. It took me a while to really understand it all, and I still don't think I have a good grasp on it. 1) Things I'd suggest to begin. Look at the DTML examples provided in the ParsedXML product. Try and do the same kinds of things in DTML, then try and do them in Python. 2) Read the interfaces for the DOM from the w3c. It is the clearest way to really understand how it all works. Right now, I'm trying to understand the differences between a node from childNodes and a node from getElementsByTagName. 3) Reading the source for ParsedXML. It is what I would consider complex, but after reading over it and figuring out where everything goes and how it works, it's not so bad. I am going to document what I've learned at some point, but not quite yet. I'm still working things out. I'd be glad to try and answer your questions though. I don't want to say it, but good luck, you're going to need it. :-) -Chris P.S. Really, it's not so bad. And as long as your are using a DOM that follows the spec, you'll be able to use what you learn here in other places. On Fri, 2001-11-23 at 01:01, Trygve Lorentzen wrote: Is there any documentation at all for parsedxml? I'm sure it's a good product, it's just that I don't have a clue how to use it... I have imported/added an XML doc into zope and can browse the parse tree, but what do I do from there? I wan't to create a simple addressbook app with XML as backend storage and need to be able to access the nodes through dtml or python. Preferably dtml since I am not very familiar with python (yet). I have look for documentation for hours without finding anything to help me get started. Can't find much interesting in the README files that came with the binary distribution 2.4.3 either. I also have a problem working with non ASCII-7 (norwegian) characters in the XML. They import fine with encoding = "iso-8859-1" but when I try to edit them, I get a parse error telling me that there is a wrong character encoding. I am running the binary dist of zope v.2.4.3 with python 2.1.1 on a debian 2.2 box. Regards, Trygve ________________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ Zope-xml mailing list Zope-xml@zope.org http://lists.zope.org/mailman/listinfo/zope-xml -- -------------------------------------------------------------------- Christopher N. Deckard | Lead Web Systems Developer cnd@ecn.purdue.edu | Engineering Computer Network http://www.ecn.purdue.edu/ | Purdue University ---- zlib.decompress('x\234K\316Kq((-J)M\325KM)\005\000)"\005w') --- From sean.upton at uniontrib.com Sun Nov 25 22:16:52 2001 From: sean.upton at uniontrib.com (sean.upton@uniontrib.com) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Documentation??? Message-ID: Some general tips I mights suggest... Both the getElementsByTagName() method and the childNodes attribute return/reference a sequence of items conforming to the NodeList interface definition; in other words, the same code can traverse such lists. Consider doing stuff in Python TTW scripts and not DTML; using DOM well often involves recursion, processing multiple big lists, etc. The python for this should be simple... Also, since most uses of DOM in Python are the same, since they conform to the same interfaces, it might be said that the upcoming O'Reilly books _Python & XML_ might be a good thing in the documentation department, since almost all other books on DOM have a Java slant... Also, bookmark this page as a reference: http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/idl-definitions.html Sean -----Original Message----- From: Christopher N. Deckard [mailto:cnd@ecn.purdue.edu] Sent: Sunday, November 25, 2001 2:32 PM To: trygvelo@trotterinfo.com Cc: zope-xml@zope.org Subject: Re: [Zope-xml] Documentation??? Trygve, I feel your pain. I went through the same thing. As someone else recommended, looking at the DOM spec from the w3c is how I figured out how to use it all. There are some examples in DTML which you can import, but they don't help much when it comes to actually using it in Python. It took me a while to really understand it all, and I still don't think I have a good grasp on it. 1) Things I'd suggest to begin. Look at the DTML examples provided in the ParsedXML product. Try and do the same kinds of things in DTML, then try and do them in Python. 2) Read the interfaces for the DOM from the w3c. It is the clearest way to really understand how it all works. Right now, I'm trying to understand the differences between a node from childNodes and a node from getElementsByTagName. 3) Reading the source for ParsedXML. It is what I would consider complex, but after reading over it and figuring out where everything goes and how it works, it's not so bad. I am going to document what I've learned at some point, but not quite yet. I'm still working things out. I'd be glad to try and answer your questions though. I don't want to say it, but good luck, you're going to need it. :-) -Chris P.S. Really, it's not so bad. And as long as your are using a DOM that follows the spec, you'll be able to use what you learn here in other places. On Fri, 2001-11-23 at 01:01, Trygve Lorentzen wrote: Is there any documentation at all for parsedxml? I'm sure it's a good product, it's just that I don't have a clue how to use it... I have imported/added an XML doc into zope and can browse the parse tree, but what do I do from there? I wan't to create a simple addressbook app with XML as backend storage and need to be able to access the nodes through dtml or python. Preferably dtml since I am not very familiar with python (yet). I have look for documentation for hours without finding anything to help me get started. Can't find much interesting in the README files that came with the binary distribution 2.4.3 either. I also have a problem working with non ASCII-7 (norwegian) characters in the XML. They import fine with encoding = "iso-8859-1" but when I try to edit them, I get a parse error telling me that there is a wrong character encoding. I am running the binary dist of zope v.2.4.3 with python 2.1.1 on a debian 2.2 box. Regards, Trygve ________________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com _______________________________________________ Zope-xml mailing list Zope-xml@zope.org http://lists.zope.org/mailman/listinfo/zope-xml -- -------------------------------------------------------------------- Christopher N. Deckard | Lead Web Systems Developer cnd@ecn.purdue.edu | Engineering Computer Network http://www.ecn.purdue.edu/ | Purdue University ---- zlib.decompress('x\234K\316Kq((-J)M\325KM)\005\000)"\005w') --- _______________________________________________ Zope-xml mailing list Zope-xml@zope.org http://lists.zope.org/mailman/listinfo/zope-xml From ASchmidt at arn.com Mon Nov 26 17:24:16 2001 From: ASchmidt at arn.com (Schmidt, Amy) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported Message-ID: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> Quick question... I am just getting started with ParsedXML after getting it installed (finally!). I read that the vision for ParsedXML includes supporting standards DOM, XSLT, and XPath. So far, I only see support for DOM. Is there any support for XSLT or XPath? Or is support for those standards still a vision at this point? Thanks! AMY amy schmidt interactive programmer arnoldworldwide From faassen at vet.uu.nl Tue Nov 27 14:48:40 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported In-Reply-To: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> References: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> Message-ID: <20011127204840.A17519@vet.uu.nl> Schmidt, Amy wrote: > Quick question... > > I am just getting started with ParsedXML after getting it installed > (finally!). What problems did you have installing it? > I read that the vision for ParsedXML includes supporting standards DOM, > XSLT, and XPath. So far, I only see support for DOM. Is there any support > for XSLT or XPath? Or is support for those standards still a vision at this > point? There's an XPathMethod which I released a while ago. It is a pain to install, but it seems to work (I expect there are more bugs to be flushed out as it assumes a 4DOM DOM implementation and not ParsedXML's DOM, but I haven't heard anything yet). Here's XPathMethod: http://www.zope.org/Members/faassen/XPathMethods I know Karl Anderson did some preliminary work on an XSLT method, but I haven't worked with it myself. It's basically a hack that hooks up an external XSLT processor up with the DOM, but it goes through the XML output, which seems like a waste. I'm working on trying to improve matters, of course. There are a number of developments that make me hopeful we can improve matters. Regards, Martijn From kra at monkey.org Tue Nov 27 16:18:28 2001 From: kra at monkey.org (Karl Anderson) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported In-Reply-To: Martijn Faassen's message of "Tue, 27 Nov 2001 20:48:40 +0100" References: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> <20011127204840.A17519@vet.uu.nl> Message-ID: Martijn Faassen writes: > I know Karl Anderson did some preliminary work on an XSLT method, but > I haven't worked with it myself. XSLTemplate, the zope-xml wiki gathers links like this. > It's basically a hack that hooks up > an external XSLT processor up with the DOM, Ow! It's not a hack, it's alpha code. Assuming that nobody is foolish enough to write a Zope-specific XSLT processor at this time, then using an external processor is the only choice, as well as a good choice. I think it's worth maintaining and building on. > but it goes through the > XML output, which seems like a waste. This is true, but I consider any use of an XSLT processor a waste, including giving it a DOM tree. It's never going to be blazing. Processing DOM would be better, but the best strategy is to use cacheing to avoid processing the source at all whenever possible. There are some defeciencies with Zope cacheing and with Parsed XML that get in the way of this, see the wiki, but the solutions seem pretty straightforward. -- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/ From faassen at vet.uu.nl Tue Nov 27 20:05:29 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported In-Reply-To: References: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> <20011127204840.A17519@vet.uu.nl> Message-ID: <20011128020529.A19333@vet.uu.nl> Karl Anderson wrote: > Martijn Faassen writes: > > > I know Karl Anderson did some preliminary work on an XSLT method, but > > I haven't worked with it myself. > > XSLTemplate, the zope-xml wiki gathers links like this. Ah, right..should start putting up some stuff onto that wiki again. > > It's basically a hack that hooks up > > an external XSLT processor up with the DOM, > > Ow! It's not a hack, it's alpha code. I didn't mean the code was a hack or hackish, I just mean the method of connecting ParsedXML to an XSLT processor by going through XML text is rather a hack. I know most XSLT processors sort of *assume* this happens, but I think going through some intermediate representation (such as DOM) is a lot nicer. Sorry, didn't mean to offend! > Assuming that nobody is > foolish enough to write a Zope-specific XSLT processor at this time, > then using an external processor is the only choice, as well as a good > choice. I think it's worth maintaining and building on. Yes, but the easier that external processor is to install in Zope, the better.. This means a Python implementation would be nice, for instance, with as little a set of dependencies as possible. Anyway, I should take a look at it, definitely. :) > > but it goes through the > > XML output, which seems like a waste. > > This is true, but I consider any use of an XSLT processor a waste, > including giving it a DOM tree. It's never going to be blazing. Yeah, we shouldn't expect XSLT processors to be able to sustain huge hit rates for the forseeable future. > Processing DOM would be better, but the best strategy is to use > cacheing to avoid processing the source at all whenever possible. Agreed. > There are some defeciencies with Zope cacheing and with Parsed XML > that get in the way of this, see the wiki, but the solutions seem > pretty straightforward. Should do more about this wiki, I shall have to look up the caching stuff. Thanks for the clarifications! Martijn From kra at monkey.org Tue Nov 27 20:51:54 2001 From: kra at monkey.org (Karl Anderson) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported In-Reply-To: Martijn Faassen's message of "Wed, 28 Nov 2001 02:05:29 +0100" References: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> <20011127204840.A17519@vet.uu.nl> <20011128020529.A19333@vet.uu.nl> Message-ID: Martijn Faassen writes: > > Assuming that nobody is > > foolish enough to write a Zope-specific XSLT processor at this time, > > then using an external processor is the only choice, as well as a good > > choice. I think it's worth maintaining and building on. > > Yes, but the easier that external processor is to install in Zope, the > better.. This means a Python implementation would be nice, for instance, > with as little a set of dependencies as possible. FYI, XSLTemplate in CVS uses 4XSLT, which you'll have on hand if you're playing with XML in Python :) -- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/ From faassen at vet.uu.nl Wed Nov 28 05:18:39 2001 From: faassen at vet.uu.nl (Martijn Faassen) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] Re: Casting Node to Element In-Reply-To: References: <20011124183114.A7561@vet.uu.nl> Message-ID: <20011128111839.A20642@vet.uu.nl> Trygve Lorentzen wrote: [cc to zope-xml so others can join in] > How do I cast a DOM node to a DOM Element when using ParsedXML? > > > > getAttribute is not recoknized since I loop thorugh all the childNodes of > a Node. Interface Node does not define method getAttribute. I need to cast > the Node to an Element... Python has no such concept as 'casting' as such. So, getAttribute directly won't work. What is defined on the Node interface is the 'attributes' attribute, which will be dictionary-like if it's an element (containing its attributes), and None (or _.None in DTML) if it's not. You could check for that. Alternatively you could just check for the existence of the getAttribute() method using getattr(), like (untested code):

No attribute found

 or, more clear in a Python script: # node is an argument to the Python script if getattr(node, 'getAttribute'): return node.getAttribute('id') else: return None # or whatever should be the default Confusing, all those words 'attributes'. The 'getAttribute()' one is the DOM concept (the foo="bar") stuff in XML. But 'getattr()' refers to attributes to Python objects instead. Regards, Martijn From flynt at gmx.ch Wed Nov 28 07:07:33 2001 From: flynt at gmx.ch (flynt) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported References: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> <20011127204840.A17519@vet.uu.nl> <20011128020529.A19333@vet.uu.nl> Message-ID: <3C04D385.DEAA018E@gmx.ch> Martijn Faassen wrote: > > Karl Anderson wrote: > > Martijn Faassen writes: > > > > > I know Karl Anderson did some preliminary work on an XSLT method, but > > > I haven't worked with it myself. > > > > XSLTemplate, the zope-xml wiki gathers links like this. > > Ah, right..should start putting up some stuff onto that wiki again. > > > > It's basically a hack that hooks up > > > an external XSLT processor up with the DOM, > > > > Ow! It's not a hack, it's alpha code. > > I didn't mean the code was a hack or hackish, I just mean the method of > connecting ParsedXML to an XSLT processor by going through XML text > is rather a hack. I know most XSLT processors sort of *assume* this > happens, but I think going through some intermediate representation > (such as DOM) is a lot nicer. Sorry, didn't mean to offend! > > > Assuming that nobody is > > foolish enough to write a Zope-specific XSLT processor at this time, > > then using an external processor is the only choice, as well as a good > > choice. I think it's worth maintaining and building on. > > Yes, but the easier that external processor is to install in Zope, the > better.. This means a Python implementation would be nice, for instance, > with as little a set of dependencies as possible. > > Anyway, I should take a look at it, definitely. :) > > > > but it goes through the > > > XML output, which seems like a waste. > > > > This is true, but I consider any use of an XSLT processor a waste, > > including giving it a DOM tree. It's never going to be blazing. > > Yeah, we shouldn't expect XSLT processors to be able to sustain huge > hit rates for the forseeable future. > > > Processing DOM would be better, but the best strategy is to use > > cacheing to avoid processing the source at all whenever possible. > > Agreed. > > > There are some defeciencies with Zope cacheing and with Parsed XML > > that get in the way of this, see the wiki, but the solutions seem > > pretty straightforward. > > Should do more about this wiki, I shall have to look up the caching > stuff. > > Thanks for the clarifications! > > Martijn Hi Martijn There is a quite new WikiPage (last modified on November, 21st). The people from fourthought.com want to do something with XSLT. I don't know wether you know about that: http://www.zope.org//Wikis/DevSite/Proposals/XSLTMethod Greetings --- Flynt From ASchmidt at arn.com Wed Nov 28 11:41:30 2001 From: ASchmidt at arn.com (Schmidt, Amy) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported Message-ID: <34A275DC8658D511BD5C0008C71650C02D03B5@MAIL1> Thanks for the information - it's very helpful. I didn't have any trouble installing ParsedXML itself - it just took me a while to get the development version of Python2.1 installed on my linux machine. I'm in the process of installing XPathMethod right now... it does have a lot of dependencies, but the instructions are great. As far as XSLT goes, I'll probably use ZPT to do the transformation of my XML for now. Thanks again, AMY -----Original Message----- From: Martijn Faassen [mailto:faassen@vet.uu.nl] Sent: Tuesday, November 27, 2001 2:49 PM To: Schmidt, Amy Cc: 'zope-xml@zope.org' Subject: Re: [Zope-xml] XML standards supported Schmidt, Amy wrote: > Quick question... > > I am just getting started with ParsedXML after getting it installed > (finally!). What problems did you have installing it? > I read that the vision for ParsedXML includes supporting standards DOM, > XSLT, and XPath. So far, I only see support for DOM. Is there any support > for XSLT or XPath? Or is support for those standards still a vision at this > point? There's an XPathMethod which I released a while ago. It is a pain to install, but it seems to work (I expect there are more bugs to be flushed out as it assumes a 4DOM DOM implementation and not ParsedXML's DOM, but I haven't heard anything yet). Here's XPathMethod: http://www.zope.org/Members/faassen/XPathMethods I know Karl Anderson did some preliminary work on an XSLT method, but I haven't worked with it myself. It's basically a hack that hooks up an external XSLT processor up with the DOM, but it goes through the XML output, which seems like a waste. I'm working on trying to improve matters, of course. There are a number of developments that make me hopeful we can improve matters. Regards, Martijn From kra at monkey.org Wed Nov 28 15:18:54 2001 From: kra at monkey.org (Karl Anderson) Date: Sun Aug 10 16:54:50 2008 Subject: [Zope-xml] XML standards supported In-Reply-To: flynt's message of "Wed, 28 Nov 2001 13:07:33 +0100" References: <34A275DC8658D511BD5C0008C71650C02D03AF@MAIL1> <20011127204840.A17519@vet.uu.nl> <20011128020529.A19333@vet.uu.nl> <3C04D385.DEAA018E@gmx.ch> Message-ID: flynt writes: > There is a quite new WikiPage (last modified on November, 21st). The > people from fourthought.com want to do something with XSLT. I don't know > wether you know about that: > http://www.zope.org//Wikis/DevSite/Proposals/XSLTMethod Naw, that's ancient, see the discussion & history pages. Someone made some minor edits for whatever reason, that upped the mod time. -- Karl Anderson kra@monkey.org http://www.monkey.org/~kra/