John,
I grabbed a glossary and looked up those terms. They mean the same thing now as they did when I started working with XML a few years ago. And by definition a Fusedoc is valid XML. That is what we are focusing on here. If you mean the entire fuse file is invalid, you would be right, and you'd also be missing the point of what we are discussing. We are talking about the portability of Fusedocs, and as long as Fusedocs are valid XML (which they are), then they are portable. What you are trying to say is that if you the entire fuse isn't well formed, then Fusedocs loose their portability. You are talking about two different things. And the fact that a (CF or JSP) code file has two root elements is irrelevant. Neither of the languages are well-formed by nature. When they are, we can change where Fusedocs are included in the file, but the Fusedoc standard itself will not have to change at all. I agree with you that the Fusedoc standard could benefit from some maturation. The main thing I see is the valid value of the language attribute, and the scope and data types. Fusedocs need to account for PHP and J2EE Fusebox. I'm anxiously awaiting your suggestions. Ben **************************************** Benjamin J. Edwards Synthis Corporation eMail: [EMAIL PROTECTED] Phone: 1-866-SYNTHIS x246 -----Original Message----- From: John Farrar [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 8:25 AM To: [EMAIL PROTECTED] Subject: RE: fusedoc type="" Ben, Grab a XML glossary, and look up "Valid", and then look up "Well Formed". Fusedoc is well formed but the inclusion of the XML and the template in the same script means there are at least two root level elements. It is not an "Valid XML Document". This means you cannot use common XML tools to read and mine the data. You must parse the scripts to grab the XML portion of the script out of the script. Fusebox right now is running on interpreted code or on cached interpreted code. There are languages that would destroy fusebox portability in the fusedoc area. The general XML standards are better suited for portability than JavaDocs standards. It is time for FuseDoc to mature a bit an grow in it's social circle... that is what I am saying. Let's not be like Wang computers who died out thinking they had innovated enough... no more change was needed. (I don't think anyone thinks that here... but just said that because this community has many members who make things holy and untouchable until the Fusebox Pope and Cardinals pass down the new truths that replace the old truths. Then the things several people have been saying become reality to them.) So, the short of it is... if I want to read a Fusedoc in and parse it... how difficult would it be just to get the data structure. You have to read the file in as text, parse the file to get the data block and then pass the data block into an XML parser. It should be read and parse the file! This will make it easier for more tools to be made to create, manage and respond to fusedocs. It is the same concept as the 'core fusedoc standard'. The simpler the core is, the more global the standard is for the community. John >>> [EMAIL PROTECTED] 06/05/02 04:45PM >>> John, What Hal suggested is valid XML, and is mirrors what is done in J2EE Fusebox. The Fusedoc XML is all that is parsed (by the surrounding tag). There is not multiple root elements in what he described. Parsing the XML and then passing the data back is indeed portable. You don't parse data out of the XML then pass it to a handler, *the XML is the data* that is passed to the handler. The handler is actually what gets usable data from the XML. I don't see where any of this lacks portability, am I missing something you were suggesting? Ben **************************************** Benjamin J. Edwards Synthis Corporation eMail: [EMAIL PROTECTED] Phone: 1-866-SYNTHIS x246 -----Original Message----- From: John Farrar [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 3:32 PM To: [EMAIL PROTECTED] Subject: RE: fusedoc type="" Hal, Not quite! It is a valid xhtml... but you cannot have more than one root element and be valid XML. There is also other possible issues that could come up by the parser reading history and picking up something it thought was code. It is a step in the right direction... and a great one. Yet, valid XML from the documentation I have read will have to be separated from the file. (like... dtd's, schema's, xsl's, wsdl's...) I don't think the fusebox group will get the W3C to change the standard so we can do XML our own way. Therefore, we will have to write a parser to grab the XML data block... then pass the data block to our FuseDoc handler. This will mean the FuseDocs will lack portability. FuseDocs should work as global as possible when possible. The standard should not change from Java, PHP and CFM. This would require separation once again to meet with the universal FuseBox base standards where you can use the same standards everywhere. John >>> [EMAIL PROTECTED] 06/05/02 03:20PM >>> John, Fusedocs was always designed with the idea that once XML parsers became more prevalent, we could drop the comments tags. Thus on MX, we have: <cfxml variable="dsp_ThisFuse.cfm"> <fusedoc...> </fusedoc> </cfxml> That's perfectly valid XML. -----Original Message----- From: John Farrar [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 8:35 AM To: [EMAIL PROTECTED] Subject: Re: fusedoc type="" Slightly off focus... With web services we have wsdl's... separate files... shouldn't we do the same type of thing with fuse descriptions? Fusedocs is nice but not very accessable. It has been out for two years and it is burried inside of a file in a way that fundamemtally is not 'Valid XML'. I was thinking of working up a fdl (fuse description language) that followed the basics of fusedoc... but was separate. It even seems possible that each circuit could have the fusedocs nested together. This would work for all fuses in the root directory, nested fuse group directories (queries, action, display, etc.), and even MVC. Just a question... but I would like to see something more readily accessable and something we could write directly to with ColdFusion MX tools. John ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
