April 2010 - 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