I like to have one docbook xml document that has content for several target audiences. Is there a filter that enables me to filter out the stuff only needed for "advanced" users?
The level attribute is invented by me to express what I have in mind.
<?xml version="1.0"?>
<book>
<title lang="en">Documentation</title>
<chapter id="introduction" level="advanced">
<title>Introduction for advanced users</title>
</chapter>
<chapter id="introduction" level="basic">
<title>Introduction for basic users</title>
</chapter>
<chapter id="ch1">
<para level="basic">Just press the button</para>
<para level="advanced">
Go to preferences to set your
needs and then start the process
by pressing the button.
</para>
</chapter>
</book>
DocBook does not have a level attribute. Perhaps you meant userlevel?
If you are using the DocBook XSL stylesheets to transform your documents, they have built-in support for profiling (conditional text). To use it you need to
use the profiling-enabled version of the stylesheet (e.g. use html/profile-docbook.xsl instead of the usual html/docbook.xsl), and
specify the attribute values you want to profile on via a parameter (e.g. set profile.userlevel to basic).
Chapter 26 of Bob Stayton's DocBook XSL: The Complete Guide has all the details.
Two ways, off the top of my head:
Write a quick script that takes the level as a parameter and, using XPath or regular expressions, that only spits out the XML you want.
Write an XSLT transformation that will spit out the XML you want.
(2) is cleaner, but (1) is probably faster to write up.
Related
I'm trying to add refinements to my google custom search.
I have meta tags on just about every page of the site, such as
<meta name="type-id" content="241" />
Where there are many different types, and I want to have one refinement for each type.
In the docs, it says
You can also use these more:pagemap: operators with refinement labels
But I have been unable to do that.
Note that I have had success using more:pagemap:metatags-type-id:241 in the search input, or as a webSearchQueryAddition - but despite googles docs, I haven't been able to get it to work with a refinement.
Here's a sample from my cse.xml (removing some attributes from the CustomSearchEngine tag):
<?xml version="1.0" encoding="UTF-8"?>
<CustomSearchEngine>
<Title>Test</Title>
<Context>
<Facet>
<FacetItem>
<Label name="videos" mode="FILTER">
<Rewrite>more:p:metatags-article-keyword:121</Rewrite>
</Label>
<Title>Videos</Title>
</FacetItem>
</Facet>
</Context>
</CustomSearchEngine>
Is this supposed to work? Am I using wrong syntax in the rewrite rule? Has anyone else done something like this?
Your label in the facet should be mode="BOOST" if you want to restrict to a structured data field within the scope of your engine.
<Facet>
<FacetItem>
<Label name="videos" mode="BOOST">
<Rewrite>more:p:metatags-article-keyword:121</Rewrite>
</Label>
<Title>Videos</Title>
</FacetItem>
</Facet>
I'm using asciidoctor with the docbook backend for books. In the past I wrote DocBook, which allows me to declare named entities that I use throughout the book:
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE book [
<!ENTITY class "Galactic TOP SECRET">
<!ENTITY project "World Domination">
<!ENTITY product "Illuminati Mind Control Chemtrail Spray System CSS-2020">
]>
<book ...>
...
What about our &class; &project;?
Is our &product; working?
...
</book>
:-)
I haven't found a way to tell asciidoctor to insert the DOCTYPE declaration between the XML processing instruction and the <book> element. So I resorted to --no-header-footer and prepending the header and footer lines. Is there a better way to do this? Something like a named entity definition directive? An include mechanism?
Do you have to use Docbook entity declarations? Asciidoctor has "attributes" that can serve the same purpose: https://asciidoctor.org/docs/user-manual/#attributes
For example, you can define an attribute within your document:
:class: Galactic TOP SECRET
Then later in your document, you can use the attribute:
"Billy, come up to the front and address the {class}." said the teacher.
When you transform your document to Docbook, you would see:
<simpara>"Billy, come up to the front and address the Galactic TOP SECRET."
said the teacher.</simpara>
If you do have to use Docbook entity declarations, you might use some XSL to transform the XML you get into the XML you want.
>> ? xml
No information on xml
There's parse-xml but it seems to me that it was for Rebol2.
I've searched for xml scripts in rebol.org and found xml-object.r that seemed to me like the most up to date from all searches.
I know about altxml, too, but the examples given are for html.
So, I'd like to ask about my choices if I want to parse and use information of +1GB of files of this simplified structure:
<?xml version="1.0" encoding="Windows-1252" standalone="yes"?>
<SalesFile xmlns="urn:StandardSalesFile-1.0">
<Header>
<SalesFileVersion>1.01</SalesFileVersion>
<DateCreation>2014-04-30</DateCreation>
</Header>
<SalesInvoices>
<Invoice>
<InvoiceNo>INV 1/1</InvoiceNo>
<DocumentStatus>
<InvoiceStatus>N</InvoiceStatus>
<InvoiceStatusDate>2014-01-03T17:57:59</InvoiceStatusDate>
</DocumentStatus>
</Invoice>
<Invoice>
<InvoiceNo>INV 2/1</InvoiceNo>
<DocumentStatus>
<InvoiceStatus>N</InvoiceStatus>
<InvoiceStatusDate>2014-01-03T17:59:12</InvoiceStatusDate>
</DocumentStatus>
</Invoice>
</SalesInvoices>
</SalesFile>
Is Rebol3 going to have a parse-xml tool? Should I use xml-object? If so how? Because it's still beyong my novice level of the language. Other option?
There is also a Rebol 3 library by Christopher Ross-Gill called alt-xml.
http://www.ross-gill.com/page/XML_and_REBOL
This can translate the XML to either a block! or object! representation.
Your question states that these XML files are large and may not fit in main memory. I would suggest that creating 1GB XML files is not best practice as many parsers, including this one, do attempt to load the files into memory.
To support this you will have to chunk the files yourself by using open on the file and copy/part chunks out of the file. This is a bit messy, but it will work.
One way to make this cleaner is to use parse as per HostileFork's suggestion and modify the series as you parse it. Parse is very flexible in this regard.
Ideally parse would be able to work directly on port! objects, but this is only a future wish list item at the moment.
Do you really need to deal with the XML file as structure? If not, have you considered just using PARSE?
(Warning: the following is untested, I'm just presenting the concept.)
Invoices: copy []
parse my-doc [
<?xml version="1.0" encoding="Windows-1252" standalone="yes"?>
thru <SalesFile xmlns="urn:StandardSalesFile-1.0">
thru <Header>
thru <SalesFileVersion> copy SalesFileVersion to </SalesFileVersion>
</SalesFileVersion>
thru <DateCreation> copy DateCreation to </DateCreation>
</DateCreation>
thru </Header>
thru <SalesInvoices>
any [
thru <Invoice>
(Invoice: object [])
thru <InvoiceNo> copy InvoiceNo to </InvoiceNo>
</InvoiceNo>
(Invoice/No: InvoiceNo)
thru <DocumentStatus>
thru <InvoiceStatus> copy InvoiceStatus to </InvoiceStatus>
</InvoiceStatus>
(Invoice/Status: InvoiceStatus)
thru <InvoiceStatusDate> copy InvoiceStatusDate to </InvoiceStatusDate>
</InvoiceStatusDate>
(Invoice/StatusDate: InvoiceStatusDate)
thru </DocumentStatus>
thru </Invoice>
]
thru </SalesInvoices>
thru </SalesFile>
to end
]
If you know you have well-formed XML and don't want a dependency on a library for processing clunky-ol' XML, Rebol can get pretty far and clear with PARSE. As TAG! is just a subclass of string, you can make things look relatively literate. And it's much more lightweight to just work with the strings.
Though if structural manipulations are required, you'll need something that makes a DOM. Altxml is the go-to right now, AFAIK.
(Hmm...I had a name for the pattern copy x to <foo> <foo> that escapes me at the moment, but this is a good case for it.)
%Rebol-Dom.r or %rebol-dom-mdlparser.r,
If your willing to use rebol2 with parse to seek thru to the node-name, then copy a chunk of data, you could feed that to Rebol-Dom.r getnodename "salesInvoice" and append that node-element to a block repetitively.
I am attempting to make use of Microsoft's Log Parser 2.2. I am pointing my Log Parser at an XML file. I would like to obtain certain information from the XML file and then reuse this information within the query. I have created some pseudo code below:
GET UNIQUE *WINDOW_NAMES*
FOR EACH *WINDOW_NAME*
{
GET WINDOW_ATTRIBUTE_ONE;
GET WINDOW_ATTRIBUTE_TWO;
}
Would this be possible with Log Parser 2.2?
An extract of the XML document:
<windows>
<window>
<name>
Window One
</name>
<visible>
Visible
</visible>
<stayontop>
True
</stayontop>
</window>
<window>
<name>
Window Two
</name>
<visible>
Visible
</visible>
<stayontop>
False
</stayontop>
</window>
<window>
<name>
Window Three
</name>
<visible>
Invisible
</visible>
<stayontop>
True
</stayontop>
</window>
</windows>
You might use the TPL output format to generate a (set of) queries based on the results of your first query, and then run logparser on the output file.
SQL, in any form, and the LogParser variety especially, is not well-suited for looping. However, if all you're trying to do is get at the data elements, then this query might do the job:
LogParser -i:XML "file.xml#/windows/window"
This will output a table with the fields name, visible, and stayontop, and a row for each "window". You can then save/output this data using one of the LogParser output options (see LogParser -h or the LogParser Windows Help file for more details).
I am using the XMLUpdate to update an xml formatted file in MSBuild. It updates fine but adds <?xml version="1.0" encoding="utf-8"?> at the top after update. Here is my statement that updates
<Import Project="C:\Program Files\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets" />
<XmlUpdate XmlFileName="$(AppName).alx" Xpath="/loader/application/version" Value="$(AppVersion)" />
Is it possible to update without the xml element at the top?
Thanks
Ponnu
The <?xml ...> is more of a descriptor than a real XML element. It describes your document and, for example defines the encoding. It won't interfere with your existing elements. I think it is even a standard feature of a XML document (but I don't have the specs handy)