You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Tarek Hammoud <ma...@c158163-a.mntp1.il.home.com> on 2000/10/15 19:43:41 UTC
Complex types from different name spaces
Hello,
We are writing a Rational Rose script to create an XML schema for our
domain objects. We want to avoid using imports for readability
purposes and include all complex types in one schema file for a given
domain object. The domain objects name space is determined by their
java package name which maps pretty nicely to an XML name space.
Our domain objects inherit base objects that are defined in a
different java package. As mentioned before, we do not want to use
imports. For a given target name space (that of the domain object),
can we defined complex types that belong to a different name space
(the base classes) in the same schema file? If so, what will the syntax look like ?
Tarek Hammoud
Citadel Investment group LLC.
Re: Problems with xsl-transformations using Xalan
Posted by Christian NENTWICH <c....@cs.ucl.ac.uk>.
> Isn't there any opportunity to write just simple html-tags like <br>
> using xalan??
Just write <br/>, xalan should transform it properly into <br> (if html
output is selected)
c.
RE: Problems with xsl-transformations using Xalan
Posted by Tako Schotanus <qu...@palacio-cristal.com>.
> Another test using <br> did even fail because this expression
> ended unchangeds in the html-document.
But you can use:
<xsl:text disable-output-escaping="yes"><br></xsl:text>
(there is a similar attribute for <xsl:value-of>)
Cheers,
-Tako
>
> Isn't there any opportunity to write just simple html-tags like <br>
> using xalan??
> Greetings,
> Torben
>
> --
> Torben Wedekind, Dipl.-Ing., System Developer
>
> Smarten Software / Italia
> 00135 Roma, Via della Camilluccia, 693
> Phone: (+39)0636298427 Fax: (+39)0636290974
> http://www.smarten.com mailto:torben@cpg.it
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
Problems with xsl-transformations using Xalan
Posted by Torben Wedekind <to...@cpg.it>.
I our application we use xalan to transform our results, formatted as
XML-DOM, into html to view them in a browser. Above is an example of the
xsl we write for this:
<xsl:template match="PartyData">
<table bgcolor="lime" border="1">
<xsl:apply-templates select="DataAttribute[@name='Nome']"/>
<xsl:apply-templates select="DataAttribute[@name='Cognome']"/><br>
<xsl:apply-templates select="DataAttribute[@name='Indirizzo']"/></br>
<xsl:apply-templates select="DataAttribute[@name='Cap']"/> 
<xsl:apply-templates select="DataAttribute[@name='Localita']"/>
</table>
</xsl:template>
Unfortunatly html is in some tags not xml-compatible ("<br>", "<li>"),
but the XSLTProcessor demands wellformed xsl-document and we would get a
Parseexception using these.
So we made the workaround writing instaead of "<br>" "<br></br>".
Because the XSLTProcessor transforms this into "<br/>" what was not
understood by the browser we used then "<br> </br>". But in this
case the browser interpreted it as two "<br>" instead one.
So no we found the solution above with the disatvantage to be able to
use "<br>" only in pairs.
Another test using <br> did even fail because this expression
ended unchangeds in the html-document.
Isn't there any opportunity to write just simple html-tags like <br>
using xalan??
Greetings,
Torben
--
Torben Wedekind, Dipl.-Ing., System Developer
Smarten Software / Italia
00135 Roma, Via della Camilluccia, 693
Phone: (+39)0636298427 Fax: (+39)0636290974
http://www.smarten.com mailto:torben@cpg.it
Re: Complex types from different name spaces
Posted by Curt Arnold <Cu...@techie.com>.
I don't think it would be advisable to split the schema for one
namespace over several files. If you gained any readability, it would
be lost by the potential run-time expense of multiple http requests or
file open's to get each included file.
If you needed to split the schema for some specific reason, you would
use <include>'s. <import>'s say that you are importing a specific
namespace but schemaLocation is only a hint to the location. Having
multiple <import>'s would be interpreted as duplicates and the processor
would be free to choose any of the three URL's (or any other location
that it wants) as the location of the definition for the namespace.
Re: Complex types from different name spaces
Posted by Tarek Hammoud <ma...@c158163-a.mntp1.il.home.com>.
Curt,
Thank you for your answer. Our domain objects might reference many other
objects (from the same namespace) and some fro a different name space. It
seems that you are saying that we should import the other name space classes
with which I believe that you are correct. How about the other classes from
the same name space, should we import or include in the schema ? When do you
import vs embed complexTypes if the target name space is the same as
"included" type ?
Tarek
----- Original Message -----
From: "Curt Arnold" <Cu...@techie.com>
To: <xe...@xml.apache.org>
Sent: Sunday, October 15, 2000 4:13 PM
Subject: Re: Complex types from different name spaces
> Nope, imports are by design the only mechanism provided in the physical
> representation for referencing schema component definitions from
> different namespaces.
>
> Why do you think use of imports makes the schema file less readable?
> You would not try to define the java classes in different packages in
> one .java file. If you are talking about document instance authors,
> they should be reading a help file or HTML documentation generated from
> the schema, not the schema itself.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
>
Re: Complex types from different name spaces
Posted by Curt Arnold <Cu...@techie.com>.
Nope, imports are by design the only mechanism provided in the physical
representation for referencing schema component definitions from
different namespaces.
Why do you think use of imports makes the schema file less readable?
You would not try to define the java classes in different packages in
one .java file. If you are talking about document instance authors,
they should be reading a help file or HTML documentation generated from
the schema, not the schema itself.