- oXygen-user - www.oxygenxml.com

Warning message in Results window
by Gabrielle Burns 08 Apr '10

08 Apr '10

In Oxygen 11.2 and previous versions, the Results window lists this commonly repeated warning: The HTML tag "?xml version="1.0" encoding="UTF-8"?" is not a valid HTML tag (it does not begin with an alphanumeric character). Each of the DITA templates provided in Oxygen includes this standard notation at the top of the xml file: <?xml version='1.0' encoding='UTF-8'?> Is there some action you recommend to eliminate this error, such as removing this tag at the top of the xml files? Thank you. Regards, Gabrielle Burns Information Products Developer BRO Software Applications Breault Research Organization, Inc. gburns(a)breault.com

2 1

Re: [oXygen-user] 11.2 XPath box in Find/Replace stuck?
by Sorin Ristache 06 Apr '10

06 Apr '10

Thank you for the files. Now I can reproduce it on Windows too. We will fix the problem and we will notify you about a new build of Oxygen. Regards, Sorin Markus Flatscher wrote: > Sorin, > > thank you again for looking into this so thoroughly. I'm still getting > the unexpected behavior with a minimum limit option of 50MB, even after > restarting/re-opening the file. > > I attached a file (JSMN-01-09.xml) and my preferences (global-opts.xml). > Please don't publish JSMN-01-09.xml to the list, that data is copyrighted. > > Thank you very much, > > Markus > > Sorin Ristache wrote: >> Hello, >> >> From our tests the XPath field is disabled in the Find/Replace dialog >> only if the file size is larger than the minimum limit set in the >> option "Optimize loading ..." at the moment of opening the file in >> Text editing mode. If you increase the value of the minimum limit >> option above the file size *after* opening the file you have to reopen >> the file in order to disable the large file support for that file >> which will re-enable the XPath field. >> >> If the value of the option is larger than the file size when you open >> the file in Text editing mode *and* the XML file is well-formed the >> XPath field is enabled. This is the behavior that I get on Mac and >> Windows in both the current build (the Download page of the website) >> and the build 2010031611. >> >> If the value of the option is larger than the file size please attach >> a zip archive with a sample file for reproducing the problem. >> >> >> Thank you, >> Sorin >> >> >> Markus Flatscher wrote: >>> Sorin, >>> >>> that's good to know, thanks for the explanation. >>> >>> However, changing the setting you mentioned did not solve my problem: >>> with oXygen 11.2 build 2010031611 (Mac OS X), I get the stripped-down >>> behavior (no real-time evaluation, no XPath in Find/Replace, etc.) >>> even with a file of 1.7 MB on disk and a setting of 50 MB under >>> 'Optimize loading…' in Preferences -> Editor -> Open/Save -> >>> Performance. >>> >>> M. >>> >>> Sorin Ristache wrote: >>>> Hello, >>>> >>>> The XPath field is disabled if the file size is larger than the >>>> minimum limit for large files that is set in Preferences -> Editor >>>> -> Open/Save -> Performance. It is one of the limitations of the >>>> support for editing very large files: >>>> >>>> http://www.oxygenxml.com/doc/ug-oxygen/large-file-editor.html >>>> >>>> These limitations try to avoid OutOfMemory errors and also improve >>>> the editing speed for very large files. >>>> >>>> >>>> Regards, >>>> Sorin >>>> >>>> >>>> Markus Flatscher wrote: >>>> >>>>> Sorin, >>>>> >>>>> yes, my data is well-formed. Is it possible that this is related to >>>>> file size? It doesn't seem to happen with small files, but only >>>>> with files of a size of 15K lines or so. >>>>> >>>>> Markus >>>>> >>>>> Sorin Ristache wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> The XPath field is activated in the Find/Replace diaog only if the >>>>>> document is well-formed XML. An XPath expression cannot be applied >>>>>> on a text fragment that is not well-formed XML. Is your document a >>>>>> well-formed XML one? If yes please post a small sample for >>>>>> reproducing the problem. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Sorin >> >

1 0

Re: [oXygen-user] 11.2 XPath box in Find/Replace stuck?
by Sorin Ristache 02 Apr '10

02 Apr '10

Hello, From our tests the XPath field is disabled in the Find/Replace dialog only if the file size is larger than the minimum limit set in the option "Optimize loading ..." at the moment of opening the file in Text editing mode. If you increase the value of the minimum limit option above the file size *after* opening the file you have to reopen the file in order to disable the large file support for that file which will re-enable the XPath field. If the value of the option is larger than the file size when you open the file in Text editing mode *and* the XML file is well-formed the XPath field is enabled. This is the behavior that I get on Mac and Windows in both the current build (the Download page of the website) and the build 2010031611. If the value of the option is larger than the file size please attach a zip archive with a sample file for reproducing the problem. Thank you, Sorin Markus Flatscher wrote: > Sorin, > > that's good to know, thanks for the explanation. > > However, changing the setting you mentioned did not solve my problem: > with oXygen 11.2 build 2010031611 (Mac OS X), I get the stripped-down > behavior (no real-time evaluation, no XPath in Find/Replace, etc.) even > with a file of 1.7 MB on disk and a setting of 50 MB under 'Optimize > loading…' in Preferences -> Editor -> Open/Save -> Performance. > > M. > > Sorin Ristache wrote: >> Hello, >> >> The XPath field is disabled if the file size is larger than the >> minimum limit for large files that is set in Preferences -> Editor -> >> Open/Save -> Performance. It is one of the limitations of the support >> for editing very large files: >> >> http://www.oxygenxml.com/doc/ug-oxygen/large-file-editor.html >> >> These limitations try to avoid OutOfMemory errors and also improve the >> editing speed for very large files. >> >> >> Regards, >> Sorin >> >> >> Markus Flatscher wrote: >> >>> Sorin, >>> >>> yes, my data is well-formed. Is it possible that this is related to >>> file size? It doesn't seem to happen with small files, but only with >>> files of a size of 15K lines or so. >>> >>> Markus >>> >>> Sorin Ristache wrote: >>> >>>> Hello, >>>> >>>> The XPath field is activated in the Find/Replace diaog only if the >>>> document is well-formed XML. An XPath expression cannot be applied >>>> on a text fragment that is not well-formed XML. Is your document a >>>> well-formed XML one? If yes please post a small sample for >>>> reproducing the problem. >>>> >>>> >>>> Regards, >>>> Sorin

1 0

validation problem for CODE element in docbook 5?
by Robert Nagle 01 Apr '10

01 Apr '10

Hi, I'm creating a docbook 5 document in the latest Oxygen, and got a strange validation error. Here is what I wrote: <para> <code> <meta content="Home Page for Dick Solomon." name="description" /> </code></para> Here is the error message I receive: SystemID: I:\My Documents\work-related\\quickguide.xml Engine name: Jing Severity: error Description: element "meta" not allowed anywhere; expected the element end-tag, text or element "alt", "anchor", "annotation", "biblioref", "classname", "exceptionname", "function", "indexterm", "initializer", "inlinemediaobject", "interfacename", "link", "methodname", "modifier", "olink", "ooclass", "ooexception", "oointerface", "parameter", "phrase", "remark", "replaceable", "returnvalue", "subscript", "superscript", "type", "varname" or "xref" Start location: 157:99 It seems that the validator is trying to process the contents of the code element when in fact the code element allows text inside it http://www.docbook.org/tdg5/en/html/code.html Or am I missing something obvious? -- Robert Nagle

3 3

Re: [oXygen-user] Format disables JQuery script( more files)
by Radu Coravu 30 Mar '10

30 Mar '10

Hi Mark, I'm forwarding the solution to the users list, maybe some other people might find it useful. The problem is that by default pretty print in Oxygen collapses empty tags so that: <script type="text/JavaScript" xml:space="preserve" src="http://test/test.js"></script> becomes: <script type="text/JavaScript" xml:space="preserve" src="http://test/test.js"/> of course the 2 versions are XML equivalent but the browser wants only the first notation. So in the Oxygen Preferences->"Editor / Format / XML" page you can check the checkbox "Expand empty elements" to avoid problems like this when working with XHTML. Regards, Radu -- Radu Coravu <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com On 3/30/2010 11:04 AM, Mark Wilson wrote: > Hi Mark, > > Some samples would be great. > Just send them to our support email address if they contain private data: > http://www.oxygenxml.com/contact.html > > Regards, > Radu > -- > Radu Coravu > <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger > http://www.oxygenxml.com > > On 3/30/2010 7:33 AM, Mark Wilson wrote: >> I have an XHTML page constructed in Oxygen 11.2. It contains a >> JavaScript that works until I click the "Format and Indent" menu >> icon. After I do that, the script no longer works. Note: the script >> does not appear to change - all of the changes occur within the body >> of the HTML. >> Is this normal? I can send you the HTML page with the css files if >> that would help. >> Mark >> >> >> _______________________________________________ >> oXygen-user mailing list >> oXygen-user(a)oxygenxml.com >> http://www.oxygenxml.com/mailman/listinfo/oxygen-user >> > >

2 2

Format disables JQuery script
by Mark Wilson 30 Mar '10

30 Mar '10

I have an XHTML page constructed in Oxygen 11.2. It contains a JavaScript that works until I click the "Format and Indent" menu icon. After I do that, the script no longer works. Note: the script does not appear to change - all of the changes occur within the body of the HTML. Is this normal? I can send you the HTML page with the css files if that would help. Mark

2 1

Self-completing elements
by Mark Wilson 29 Mar '10

29 Mar '10

When I am entering elements into an XML or XSD file, the closing tag appears automatically, but that does not happen when I am working with HTML or XHTML. Is there a preferences setting to turn this on? I am using version 11.2 and it seems to me that earlier versions did the self-completion for HTML. Thanks, Mark

2 1

customizing doc type associations in AUTHOR? (Win 7 permissions)
by Robert Nagle 29 Mar '10

29 Mar '10

Hi, I am in XML Author in Win 7 and am trying to change some default settings when editing docbook. I don't like the fact that by default author will open up docbook files in Author view. I prefer for it to open in text/code view. I am using lots of xincludes, so if I open up the main index.xml, author will attempt to tie all the files together (it will also spit an error message if parts are not valid). That can be time-consuming. I see that when editing Document Type associations (DTA), you have the option to change default code view. That would seem to be the answer. But wait! 1)Oxygen is pushing me to create a duplicate DTA for docbook5 instead of editing the original DTA. This sounds logical, but really I have no idea what this means to work with a duplicated DTA. Does this mean there are now 2 DTAs pointing to Docbook instead of 1? How does Oxygen know which settings to use? Do I need to specify this in my project? How do I do this? Will I need to do this every time? 2)The other option is to change my role from Content Author to Developer. Developer seems to have edit power over DTA options. Assuming that I change my role to developer, when I change the view to Text view, it gives me this error: You have no write permissions to the store location of this document type:C:\Program Files (x86)\Oxygen XML Author 11\frameworks\docbook\docbook5.framework Now I have noticed two problems with trying to edit the original DTAs. 1)they get erased every time you upgrade. (This happens when I add something to the catalog file in that Oxygen directory too). 2)I have windows permission problems every time. On my Vista box, I would edit the Security settings for the docbook directory to allow full control; only doing this would allow Oxygen to make this change successfully. On my Win 7 box, this doesn't seem to be working. It seems to me that the Oxygen configuration options should only change things which Oxygen editor has the permissions to change. Relying on the user to figure out which security scheme to use seems unwise. Or I am totally doing this the wrong way? Thanks for your help. -- Robert Nagle

2 1

Re: [oXygen-user] Nested xincludes
by coder＠bluegumtree.com 25 Mar '10

25 Mar '10

Hi Stefan, I reproduced your test locally and, as you said, it works when I use Saxon 6.5.5 (with Oxygen 10 as a plugin within Eclipse) but not when I use Saxon-B 9.1.0.7. S. on 25/3/10 2:36 PM, Stefan Vasile <stefan(a)oxygenxml.com> wrote: > Hello, > > I tried to reproduce your problem so I created a file with the following > content: > > <?xml version="1.0" encoding="UTF-8"?> > <root xmlns:xi="http://www.w3.org/2001/XInclude"> > <xi:include href="file:///home/projects/cms/story/screen_default.xml"> > <xi:fallback> > <xi:include href="personal.xml"> > <xi:fallback> > <parseGridError > > url="file:///home/projects/cms/story/screen_default.xml" /> > </xi:fallback> > </xi:include> > </xi:fallback> > </xi:include> > </root> > > and I saved it in the Oxygen samples directory in order to reference the > already existing personal.xml file (as xinclude fallback). > Then I created a small XSL file to test the transformation and the > debugging process. > > <?xml version="1.0" encoding="UTF-8"?> > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" > xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="xs" > xmlns:xd="http://www.oxygenxml.com/ns/doc/xsl" version="1.0"> > <xsl:template match="/"> > <html> > <body> > <table> > <xsl:for-each select="//person"> > <tr> > <td><xsl:value-of select="name"/></td> > <td><xsl:value-of select="email"/></td> > </tr> > </xsl:for-each> > </table> > <br /> > </body> > </html> > </xsl:template> > </xsl:stylesheet> > > Indeed, there is a warning message that the xinclude operation failed > and the fallback will be used but the debugging process seems to > continue correctly. > Please let me know if I missed something (I tested with Oxygen 11.2 and > Saxon HE/PE/EE and Saxon 6.5.5 as XSLT processors). > > Best regards, > Stefan Vasile > http://www.oxygenxml.com > > PS: Please make sure that Options->Preferences->XML->XML Parser->"Enable > XInclude processing" is checked (that should be the default). >> Hi, >> >> I'm having trouble using the oXygen debugger with a sequence of nested >> xincludes. When the first xinclude fails (which is expected in this >> instance), the error message says "include operation failed, reverting >> to fallback" but it doesn't seem to actually progress any further. >> >> <xi:include href="file:///home/projects/cms/story/screen_default.xml"> >> <xi:fallback> >> <xi:include href="http://localhost/cms/story/screen_default.xml"> >> <xi:fallback> >> <parseGridError >> url="file:///home/projects/cms/story/screen_default.xml" /> >> </xi:fallback> >> </xi:include> >> </xi:fallback> >> </xi:include> >> >> The second xinclude instruction works perfectly when it's not nested >> within the first xinclude. >> >> Does anyone know what the problem might be and how to fix it? >> >> S. >> _______________________________________________ >> oXygen-user mailing list >> oXygen-user(a)oxygenxml.com >> http://www.oxygenxml.com/mailman/listinfo/oxygen-user >> > > > >

2 1

Nested xincludes
by coder＠bluegumtree.com 25 Mar '10

25 Mar '10

Hi, I'm having trouble using the oXygen debugger with a sequence of nested xincludes. When the first xinclude fails (which is expected in this instance), the error message says "include operation failed, reverting to fallback" but it doesn't seem to actually progress any further. <xi:include href="file:///home/projects/cms/story/screen_default.xml"> <xi:fallback> <xi:include href="http://localhost/cms/story/screen_default.xml"> <xi:fallback> <parseGridError url="file:///home/projects/cms/story/screen_default.xml" /> </xi:fallback> </xi:include> </xi:fallback> </xi:include> The second xinclude instruction works perfectly when it's not nested within the first xinclude. Does anyone know what the problem might be and how to fix it? S.

2 1