boen_robot

First stop: really interesting use of XML and XSLT. Nice . I think the first quote in my signature actually refers to projects like this one .Khm... anyway... looking at the GUI program, it doesn't have a node with name "name", but it does have an attribute with that name. If all other of your XPath expressions are correct, the answer should be: <node name="charsheet"> <node> <xsl:attribute name="name"> <xsl:value-of select="@name"/> </xsl:attribute> Notice the "@" before the name. It's an XPath selector for attributes.By the way, there's another method of using attributes, which I prefer. If you have some spare time, experiment with it: <node name="charsheet"> <xsl:variable name="NAME" select="@name" /> <node name="{$NAME}"> It takes less code, easier to read, and can be used multiple times over as long as it's withing the element it's used in (in our case: multiple times inside the <node name="charset"> element.

Or a JavaScript that would hide the desired images and show them when appropriate links/buttons are here, simillarly to scripts used for tree-like menus.However, such thing would let all images download, though the shown will be with priority, so a server side script is truly reccomended.

li {list-style: I don't know what should be here}?

There's no "must"s in XML and related technologies. However, there's always "better" possibilities, when server side scripting is avaiable.Server side script however doesn't refer to C#. It refers only to languages such as:PHP, ASP(.NET), Cold Fusion, Jigsaw (a.k.a. CGI), JSP, Perl, etc.Web services that would use XML would be any, which doesn't contact with a huge kind of database. However, if you want interactivity, you'll have to use at least JavaScript.You can also use XML to carry the data for the site and use XSLT to tranform the XML into XHTML. But that doesn't allow interactivity again.Conclusion: There's a need for SOME language. Which one is highly up to you.

Well, again I must say, that only the main site... the XHTML site must be with SSL encrypted protocol. The SSL allows every submitted information to be delivered to the end point, without a risk of being viewed by phishers (people who monitor traffic on certain sites, so they can steal a user's details).There's no need for encrypting the WAP site, scince payments are done to the operator, not by submitting some info to the site. SSL encryption is requred only when there is info to be sent. Yeah, the operator should know how to proceed with the "link billing" and all.Infact, it's NOT reccomended to have such encryption on WAP site, scince some users have old phones, which don't support this kind of encryption. All modern computer browsers do support this encryption properly and as said above, most users are smart enough not to buy from a site without it.As for "how", here's a good kind of plan:1. Look for a coder to build a WEB site. By the way, ask for a tableless designs and CSS for mobile phones. This may cost you extra, but XHTML enabled mobile phones would be able to browse through the main site, bringing you extra possibilities. Of cource, that's all optional, scince you'll have a WAP site anyway.2. Look for host offers with options for SSL/HTTPS protocol. If they allow you to have both HTTP and HTTPS pages, it's the best. Otherwise, you'll need to support two kinds of (sub)domains (that's what I meant by saying that encrypting the protocol is only a "detail").3. Speak with the operators for the billing stuff and all.4. Build and fill the WAP site.5. Look for a SSL certificate issuer and get an SSL certificate. The most trusted one is VerySign though. You need it for proper SSL "trust" or so to say. You shouldn't get it before the WAP site is built, because before issueing, they check the organization's activities. Having a working WAP site would make it easier for them to issue you the certificate.6. Ask the coder to add E-Commerce system to the XHTML site and fill it's content.7. Import the certificate to your XHTML section of the site. Keep the WAP pages on HTTP. Ask the host or the coder for support. They are sure to know the tricks for this.Done.Most of the details in theese steps have people who know better how to deal with them. You are practically only requred to manage the whole thing.Cheers.

I think the question of the Poll is clear enough. Which one of the two vector graphic animations you prefer and why?I personally like SVG for quite a few reasons:1. Support is no longer something to compare. Adobe SVG viewer helps IE6 and Firefox and it could be installed on Opera. Opera 9 and Firefox have some native support for it too.2. It's text based, meaning there's not a "must" for a single commercial editor to stick with.3. It could be binded with XML data, making it very flexible.4. A lot of phones are actually now supporting SVG Tiny, though they are not as cheap and popular yet. Still: using the same thing for both Phones and computer screens sounds attractive.5. No need to learn additional language for scripting. JavaScript could be used inside SVG to give it all requred functionality which can't be delivered directly by SVG.

I have no idea what theese coding camps are actually. Those things you wrote sound more like kinds of mobile networks, which is quite different.If users get sticked by security issues, they won't give you a second chance. If you are going to make a credit card payment, it HAS to include an SSL encryption from the first time. It's not the "XHTML" which has to be secure. It's the HTTP protocol, but that's just a detail. A phone payment won't requre this though, scince everything is done inside the operator's system.By the way, I don't get it.... how can you possibly organize a payment that would not requre a computer at all? How can anyone preview the thing he/she wants properly? And most importantly: How are they going to pay?There are only 2 ways I can think of:1. SMS payment. A user memorizes some code and types it as an SMS to an appropriate number for the appropriate price.2. Traffic payment. The payment is done when the user clicks on a download button and his internet bill gets extra charged with the appropriate price.In both ways: you need operator's support. The more- the better.If there was one central operator (the same way there's ICANN for the world wide web), there would be ONLY mobile phone payments .

The HTML tutorial on W3Schools is based on HTML 4.01, so this means you already know it. Move to XHTML and CSS now. Most of the advanced part in the HTML tutorial doesn't contain anything useful.

The codediv.p {CSS properties here} Will apply the CSS properties to all divs in the (X)HTML who look like this: <div class="p">Some content to be styled</div><div>But this content won't, because it doesn't have a class p.</div> And a code in the CSS which looks like this: div p {CSS properties here} Will apply the styles to all p elements inside div ones, like this: <p>This content is not going to be styled.</p><div>This content is not be styled either, but <p>this one will, because this p element is inside a div.</p><div> Following the above logic, the code: div, p {CSS properties here} Will style both div and p elements. Example: <p>This element is going to be styled</p><div>And this one too</div>

That's not exactly right. Here yo go:div.p = styles every div with class p.div p = styles all p's contained within a div only.div, p = styles all div and p's

If you mean that the systax of XML is colored, well... yes it is. They already told you XML is different then XHTML. And XML files without stylesheets applyed to them leave to the browser to decide how to make them look. IE automatically applyes it's systax coloring for previewing purposes, but it doesn't allow you to edit the source directly and (as you have noticed) it hides some parts (such as the doctype).

Why don't you group all the things in the XML file and access them separatly. Example: <people><person><fname>Allan</fname><lname>Rogers</lname></person><person><fname>Madonna</fname></person><person><fname>Peter</fname><lname>Smith</lname></person></people>

True, I admit this is a very "boring like" system. It's normal that you don't care that much for security, but a large varaity of users does, so you should compile with their needs.An SMS payment did came into my mind, however, it would probably cover only one country (Norway?) and perhaps with later investments, one or two more countries. I don't think it would work as international kind of payment. If you could make an international SMS payment system that would be supported by all mobile operators and would be on internationally acceptable prizes, you'll be a world hit.

Well, the easiest way I can think of is to archive (zip) your videos, so the users would be forced to download them first. If you want them to save raw movies, then... I don't think there's a way. It's all user's settings. At least, I think it's only that though.

<xsl:stylesheet version="1.0"xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:template match="/"><html><body> <h2>My note</h2> <xsl:apply-templates select="note/subject"/></body></html></xsl:template> <xsl:template match="note/subject"> <p> <xsl:apply-templates select="tag1"/> <xsl:apply-templates select="tag4"/> </p> </xsl:template> <xsl:template match="tag1"> Topic: <xsl:value-of select="."/><br/> </xsl:template> <xsl:template match="tag4"> <xsl:for-each select="."> <xsl:apply-templates select="tag2" /> <xsl:apply-templates select="contents/tag3" /> </xsl:for-each> </xsl:template> <xsl:template match="tag2"> Title: <span style="color:#ff0000"> <xsl:value-of select="."/></span> <br /> </xsl:template> <xsl:template match="contents/tag3"> <xsl:for-each select="."> <xsl:choose> <xsl:when test="tag5"> <a> <xsl:attribute name="href"> <xsl:value-of select="tag5" /> </xsl:attribute> <xsl:value-of select="tag6" /> </a><br/> </xsl:when> <xsl:otherwise> Content: <span style="color:#00f000"> <xsl:value-of select="."/> </span> <br/> </xsl:otherwise> </xsl:choose> </xsl:for-each> </xsl:template></xsl:stylesheet> I decided to take the code into my lab (Dreamwaver 8) for further investigation and this is what I got in the end. As I suspected, it's all wrong XPath expressions and nothing more. The XPath expression in the root ("/") template is optional btw. I put it just to ensure all is OK. I also added some "for-each"es, to ensure that not only the first record is shown .Btw, try to use the BBCode element to mark your code. It's easier to read and copy(for investigation) that way.

I don't want to repeat myself so here is a review from myself and my opinion for what server side language might be called the best. Still: outside factors such as hosting plans, support, etc. are thing you have to consider.

Well, when there's no alternative, a JavaScript is acceptable, but in the case of hr it's useless. And don't worry about the target replacement too. CSS3 is going to have a target property for opening links in new windows or tabs. It's just a matter of time until browsers support it though. Until then: DOM rules the world .

Mostly for accesability purposes. For example, if you use an emty div to clear floats in the body and start arranging the footer. A hr would be better because when viewed without the CSS file (example: text browsers, tuned off CSS by the user, etc.) it gives a nice horizontal line, dividing the body and the footer.Also, a purpose of the div is to hold different parts of a page. The purpose of hr is to devision between those different sections. In short: again comes the spirit of web standarts.

It depends. If the JavaScipt is stored inside an XML file, then the code would be something like:<script><xsl:value-of select="XPath expression to the script" /></script>Or if you want to call a JS file depending on a condition, you could use a conditional statemens:<xsl:variable name="script">URL to the script or a select statement inside the variable to point to a place in the XML file for the location</xsl:variable><xsl:if test="condition"><script src="{$script}"></script></xsl:if>I don't understand the question completely. What do you mean? Hm... do you mean if the JavaScript will manipulate the XHTML output or the XSLT file it's used in? If that's the case... I don't know actually. You should make some kind of test to see that.

They say there are two types of validation- Errorles one and spiritual one. The way I see it rainmo offers an errorles solution. However it doesn't get into the spirit of web standarts.As scott100 mentioned already, the hr is not deprecated. Only it's presentational attributes are. Infact, I think it's better to use a hr instead of an empty div for every purpose, not only when you need a line.

By "clean" I mean without composing the full application for yourself. For example, XSLT could be used for transforming an RSS feed and then a server side code could execute that transformation. The other way is to use the server side script to read and transform the XML and execute it in the page. The second way is not "clean" because it relyes on heavy programming which takes lots and lots of code (not to mention CPU power).The same way, I don't know about any server side XSL-FO processors that would execute the XSL-FO file and generate a PDF file from the output but I'm completely positive that a heavy and overcrowded server side script could somehow process the whole XML after you have predefined each function of XSL-FO inside the server side script itself and execute the XSL-FO as if it's a test file with predefined by script functions.That apache extension you are talking about sounds a bit different though. And I don't get it completely. Anyway, if you could preview the XSL-FO output instead of getting error there, I don't think there should be a problem. But if the error is not in the XSLT or XSL-FO, I don't know what can you do.

The way I see it, you were confused by your own structured way of presentig data . The only mistakes you have is that you misplaced the achor and it's content and thus you have wrong XPath expressions everywhere.Just to clear the things up with the link first: starting an XPath expression with a forward slash("/") makes it absolute. If you are going to use an absolute value, it should look like this: <a><xsl:attribute name="href"><xsl:value-of select="/topic/contents/tag5" /></xsl:attribute><xsl:value-of select="/topic/contents/tag6" /></a> Look at your XPath expressions. Adjustings to the XML always lead to adjustments in the XSLT. Now if I have understood your methods correctly, it should be something like this: <xsl:stylesheet version="1.0"xmlns:xsl="http://www.w3.org/1999/XSL/Transform"><xsl:template match="/"><html><body><h2>My note</h2><xsl:apply-templates/></body></html></xsl:template><xsl:template match="subject"><p><xsl:apply-templates select="tag1"/><xsl:apply-templates select="tag4"/></p></xsl:template><xsl:template match="tag1">Topic: <xsl:value-of select="."/><br/></xsl:template><xsl:template match="tag2">Title: <span style="color:#ff0000"><xsl:value-of select="."/></span><br /></xsl:template><xsl:template match="tag3"><xsl:choose><xsl:when test="tag5"><a><xsl:attribute name="href"><xsl:value-of select="tag5" /></xsl:attribute><xsl:value-of select="tag6" /></a><br/></xsl:when><xsl:otherwise><span style="color:#00f000"><xsl:value-of select="."/></span><br/></xsl:otherwise></xsl:choose></xsl:template><xsl:template match="tag4"><xsl:apply-templates select="tag2" /><xsl:apply-templates select="tag3 /></xsl:template></xsl:stylesheet> And also some small adjustments to make the XML more organized again: <tag3><tag5>C://Webdocs/java.html</tag5><tag6>content5</tag6></tag3>

There's no way without a server side script. As for what is the server side script or it's code... I have no idea. I haven't attempted this. I only know it's not possible via markup languages and client side ones.

LOL, theese are really high prisez. Hope you'll sucseed with them (though you shouldn't expect anything from me ).As for a pay function in WAP. I think it would be very difficult. Not to mention than any smart person won't buy anything from WAP. Why? There's no SSL encryption on WAP protocols. Only some "advanced" cell phones, that support XHTML sometimes have a support for SSL also.Alternative solution that you should use is to make a main site (XHTML pages) from which users would sign in and buy what they want. Then from the WAP site, they would have to login and download the thing they have paid for from a customized list of products. Unclear?Example:I go in your site and look at some good ringtone that would like to have. I create an account and I pay for it via a credit card or something on the main site. That ringtone gets inside a special section in my account. I grab my mobile phone and go into the WAP site version of your site. I login and go to the special section in which the ringtone I have bought is. I download it and the deal is over.This is certanly the best and most secure method for doing things.Yes, you could use a regular domain for a wap site. After all, a WAP site differs only with their special kind of files(WML). There are also ways with which you could have only one main page and make a server side script that would detect if the WAP or XHTML version should be used. If you don't/can't do it, you could always make something like domain.com/wap/ and domain.com that would be the XHTML site.

First stop: XSD is XML Schema Definition as far as I know. I presume you were mistyping XSL the second and third time (I can't say about the first)?In my personal opinion, again there's no point of using XSL-FO, scince you could process the XSLT with a server side script and transform the XHTML output into PDF then. Infact, I don't know if there's a "clean" way with which you could execute XSL-FO as PDF. I haven't heard of such a thing, but if there is, then XSL-FO is truly the easiest way to go.Well, of course you could use data from XML inside an XSL-FO document. The idea of XSL-FO is to format an XML data after all. If XSL-FO alone can't do it, then a combination of XSLT and XSL-FO surely can.