I added following in the OPF file.
<?xml version="1.0" encoding="UTF-8"?>
<package xmlns="http://www.idpf.org/2007/opf" version="3.0" xml:lang="en" unique-identifier="pub-id">
<metadata xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:type>ePub</dc:type>
</metadata>
but getting error by Epub validator. http://validator.idpf.org/
element "dc:type" not allowed here; expected the element end-tag or element "dc:contributor", "dc:coverage", "dc:creator", "dc:description", "dc:format", "dc:identifier", "dc:language", "dc:publisher", "dc:relation", "dc:rights", "dc:subject", "dc:title", "link" or "meta"
How to add type metadata element in the OPF file?
Package Document (.opf)
The Package Document contains information about the book including the metadata, manifest, and
spine. It also defines the version must be 3.0.
<package xmlns="http://www.idpf.org/2007/opf" unique-identifier="bookid" version="3.0" prefix="rendition: http://www.idpf.org/vocab/rendition/#">
The Metadata
Minimum, you must include the following items.
Title
ID
Language
Type
Modified-date
For Example:
<dc:title>XXXXXX</dc:title>
<dc:creator>YYYYYY</dc:creator>
<dc:source>0000000</dc:source>
<dc:identifier id="p0000000">URN:ISBN:0000000<dc:identifier>
<dc:publisher>ZZZZZZ</dc:publisher>
<dc:language>en</dc:language>
<dc:type>Text</dc:type>
<dc:format>100 pages</dc:format>
Related
I use vb6 dll/ocx without registration, using manifest file. 90% of application working ok, but one part who using VBControlExtender not working.
Dim oRegion as VBControlExtenderÂ
Set oRegion.Properties = Prop
Error: 438 object doesn't support this property or method
If register ocx then working ok!?
manifest file:
<?xml version="1.0" encoding="UTF-8"?>
<file name="Dll\XMLKontrolaNalaz.ocx">
<typelib tlbid="{AFC41DA0-934F-46CB-9421-B0798C427C74}" version="1.0" flags="" helpdir="" />
<comClass clsid="{4437736B-A865-446B-B6E4-924EBC9197A5}"
tlbid="{AFC41DA0-934F-46CB-9421-B0798C427C74}"
threadingModel="Apartment" progid="XMLKontrolaNalaz.ucTxt" />
<comClass clsid="{37AB7E7A-C924-47C0-BA6F-05C9586D4AE4}"
tlbid="{AFC41DA0-934F-46CB-9421-B0798C427C74}"
threadingModel="Apartment" progid="XMLKontrolaNalaz.ucOpt" />
...
I am using a different package name as configured in my config.xml for my windows platform target.
For example, this is my config.xml (here package name is the id element in the widget tag) in my root project folder:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<widget id="de.myapplication.mobile" version="1.1.1" ...>
And my package.phone.appxmanifest file in my windows platform folder (here the package name is the Name element in the Identity tag) contains for example this:
<Package ...>
<Identity Name="de.myWindowsApplication.mobile" Publisher="XXX" Version="1.0.0.0" />
</Package>
Now building my windows platform target with cordova build windows replaces the Name element string de.myWindowsApplication.mobile with the id element string de.myapplication.mobile from the config.xml.
(How) Can i prevent this?
I am building a Joomla package with a component, multiple modules and a plugin.
My question is, where should I place the install.sql and uninstall.sql files, relative to the package root? Right now they are at root/com_mypackage/administrator/sql/install.mysql.utf8.sql and they are defined in the component's manifest as:
<install><!-- Runs on install -->
<sql>
<file driver="mysql" charset="utf8">sql/install.mysql.utf8.sql</file>
</sql>
</install>
However, this doesn't seem right to me. Should I include administrator before the path in the <file> tag?
Of course, the component itself will be packed in its own .zip, to be included in the Package's XML install file.
No there is no need to this tag in administrator tag. you missing some in manifest.xml
for fully doc try:-
http://docs.joomla.org/Developing_a_Model-View-Controller_Component/2.5/Adding_an_install-uninstall-update_script_file
http://docs.joomla.org/Components:xml_installfile
on my end manifest.xml (my .sql in admin/install/install.mysql.utf8):-
<?xml version="1.0" encoding="utf-8"?>
<extension type="component" version="2.5" method="upgrade">
<name>Social</name>
<license>Open Source License, GPL v2 based</license>
<author>me</author>
<authorEmail>developers#me.com</authorEmail>
<authorUrl>http://www.me.com</authorUrl>
<creationDate>2012-01-01</creationDate>
<copyright>2013, me</copyright>
<version>1.1</version>
<description></description>
<!-- Installation -->
<install>
<sql>
<file driver="mysql" charset="utf8">install/install.mysql.utf8.sql</file>
</sql>
</install>
<installfile>install/install.php</installfile>
<uninstall>
<sql>
<file driver="mysql" charset="utf8">install/uninstall.mysql.utf8.sql</file>
</sql>
</uninstall>
<uninstallfile>install/uninstall.php</uninstallfile>
and rest of
Context: I am generating java classes from xsd files using maven-jaxb plugin. All my .xsd files are in a single location - src/main/resource directory.
Problem: Everything works fine when xsd's don't reference/import other xsd's with a different target namespace. However when the following xsd below (with targetNamespace="http://www.companyA.com/someservice") imports another xsd filename.xsd from a different namespace (namespace="http://www.companyB.com/"), I get the above error: Cannot resolve the name xxx to a(n) 'type definition' component.
Edit: the element name in the current xsd file is 'entityName', and its type is "companyB:entityName" (i.e.) the names are the same.
I then tried invoking xjc on this file from the command line and this generated Java classes correctly. I also made sure that in Eclipse, I am able to ctrl-click/examine source on "type="companyCdm:entityName", which correctly opens the filename.xsd file. However for some reason maven is unable to get to it.
Question: What am I missing? Why is this case (2 namespaces) different from dealing with a single namespace?
Here is my XSD:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.companyA.com/someservice"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:companyB="http://www.companyB.com/version"
targetNamespace="http://www.companyA.com/someservice"
elementFormDefault="qualified" attributeFormDefault="qualified">
<xsd:import namespace="http://www.companyB.com/version" schemaLocation="filename.xsd" />
<xsd:element name="MyName" type="MyType" />
<xsd:complexType name="MyType">
<xsd:annotation>
<xsd:documentation>
A list
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="entityName" type="companyB:entityName" maxOccurs="1" minOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Ok figured out the work-around:
I moved all the dependent xsd's (that the problematic xsd's references) plus a bunch of other un-used xsds to a separate folder and then re-generated code using maven - it works now. It appears that there was some namespace conflict with one of the other un-used xsd's i haven't yet pointed out the specific one.
The O'Rielly [Java and XML Chap3][1] says that using an InputSource will enable you to parse relative paths:
Using the savon gem, I get the following request XML:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsdl="URL"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ins0="SOME URL">
<soap:Body>
<ins0:Test xmlns="SOME URL">
</ins0:Test>
</soap:Body>
</soap:Envelope>
But it needs to be this instead:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wsdl="URL"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<Test xmlns="SOME URL">
</Test>
</soap:Body>
</soap:Envelope>
Notice ins0 was removed.
Any suggestions?
The two XML documents are equivalent, so there should be no issues as long as the document is parsed by an XML compliant agent.
The Savon generated document is simply creating a namespace prefix of ins0 for the "SOME URL" namespace. This is convenient for a large SOAP document with many elements from that namespace. In this example, the prefix is not really necessary.
The only potential issue I can see is that the Savion generated document seems to declare the ins0 namespace twice - once in the soap:Envelope and then again in the soap:Body. Seems superfluous and potentially open to error.