sexta-feira, 10 de novembro de 2017



SOAP vs REST (differences)




SOAP and REST can't be compared directly, since the first is a protocol (or at least tries to be) and the second is an architectural style. This is probably one of the sources of confusion around it, since people tend to call REST any HTTP API that isn't SOAP.
Pushing things a little and trying to establish a comparison, the main difference between SOAP and REST is the degree of coupling between client and server implementations. A SOAP client works like a custom desktop application, tightly coupled to the server. There's a rigid contract between client and server, and everything is expected to break if either side changes anything. You need constant updates following any change, but it's easier to ascertain if the contract is being followed.
A REST client is more like a browser. It's a generic client that knows how to use a protocol and standardized methods, and an application has to fit inside that. You don't violate the protocol standards by creating extra methods, you leverage on the standard methods and create the actions with them on your media type. If done right, there's less coupling, and changes can be dealt with more gracefully. A client is supposed to enter a REST service with zero knowledge of the API, except for the entry point and the media type. In SOAP, the client needs previous knowledge on everything it will be using, or it won't even begin the interaction. Additionally, a REST client can be extended by code-on-demand supplied by the server itself, the classical example being JavaScript code used to drive the interaction with another service on the client-side.
I think these are the crucial points to understand what REST is about, and how it differs from SOAP:
  • REST is protocol independent. It's not coupled to HTTP. Pretty much like you can follow an ftp link on a website, a REST application can use any protocol for which there is a standardized URI scheme.
  • REST is not a mapping of CRUD to HTTP methods. Read this answer for a detailed explanation on that.
  • REST is as standardized as the parts you're using. Security and authentication in HTTP are standardized, so that's what you use when doing REST over HTTP.
  • REST is not REST without hypermedia and HATEOAS. This means that a client only knows the entry point URI and the resources are supposed to return links the client should follow. Those fancy documentation generators that give URI patterns for everything you can do in a REST API miss the point completely. They are not only documenting something that's supposed to be following the standard, but when you do that, you're coupling the client to one particular moment in the evolution of the API, and any changes on the API have to be documented and applied, or it will break.
  • REST is the architectural style of the web itself. When you enter Stack Overflow, you know what a User, a Question and an Answer are, you know the media types, and the website provides you with the links to them. A REST API has to do the same. If we designed the web the way people think REST should be done, instead of having a home page with links to Questions and Answers, we'd have a static documentation explaining that in order to view a question, you have to take the URI stackoverflow.com/questions/<id>, replace id with the Question.id and paste that on your browser. That's nonsense, but that's what many people think REST is.
This last point can't be emphasized enough. If your clients are building URIs from templates in documentation and not getting links in the resource representations, that's not REST. Roy Fielding, the author of REST, made it clear on this blog post: REST APIs must be hypertext-driven.
With the above in mind, you'll realize that while REST might not be restricted to XML, to do it correctly with any other format you'll have to design and standardize some format for your links. Hyperlinks are standard in XML, but not in JSON. There are draft standards for JSON, like HAL.
Finally, REST isn't for everyone, and a proof of that is how most people solve their problems very well with the HTTP APIs they mistakenly called REST and never venture beyond that. REST is hard to do sometimes, especially in the beginning, but it pays over time with easier evolution on the server side, and client's resilience to changes. If you need something done quickly and easily, don't bother about getting REST right. It's probably not what you're looking for. If you need something that will have to stay online for years or even decades, then REST is for you.
shareimprove this answer


https://stackoverflow.com/questions/19884295/soap-vs-rest-differences

WebSphere Liberty z/OS Connect Makes Business Assets Accessible to Mobile Devices



For the enterprise providers of applications and data, making those business assets more accessible to your customers and employees directly translates to new business opportunities and competitive advantage. But keeping pace with these trends has been a significant challenge in the marketplace.The advent of the mobile device, as viewed by the consumer of mobile services, has been remarkable. The availability of applications and instant access to data has provided an increase in functionality and productivity that was unimagined just a few years ago. And now, cloud applications appear to be on that same adoption curve.
In most large enterprises, a majority of enterprise transactions and data—referred to here as z/OS* assets—exist on the mainframe: CICS* transactions, IMS* trans-actions and data, z/OS batch applications and more. So the question has become: What is the best way to connect consumers and their systems of engagement with these z/OS assets in an enterprise’s systems of record? A key part of that answer was recently introduced with IBM WebSphere* Liberty z/OS Connect.

What z/OS Connect Provides

Built on IBM WebSphere Application Server Liberty profile running on z/OS, z/OS Connect is a gateway that provides a simple and secure way to discover and invoke applications and data on z/OS from mobile, cloud and Web applications. It uses standardized interfaces and data, including Representational State Transfer (REST) APIs and JSON, which makes it readily accessible to Web and mobile developers. RESTful APIs are one of the key technologies used to abstract enterprise assets and, along with an API management solution, allows for the consumerization of z/OS assets as APIs.
Using these standardized interfaces and data to communicate with existing mainframe applications is one of the challenges. z/OS Connect addresses this problem by providing the capability to transform JSON name/value pairs into the data format required by back-end programs such as COBOL COPYBOOK, PL/I and C/C++ structures. Bind files contain the data field conversion information and are generated by a supplied utility. And all of this—the z/OS Connect gateway and the data transformation routines—is written in Java*, so it is IBM System z* Application Assist Processor-eligible to be offloaded to specialty engines and does not count toward processor-based licensing.
The ability to write your own REST and JSON handler has been available for some time now. Where z/OS Connect excels against other solutions is in its common and consistent interface to, and running on, the mainframe. It is able to integrate with System z facilities and z/OS subsystems that have proven qualities of service for the enterprise. In this capacity:
  • It uses System Authorization Facility for authorization checks and to control access to resources. And z/OS Connect does not expose all z/OS assets, only those identified in the Liberty Profile configuration file.
  • It works with System Management Facility to write type 120, subtype 11, records that are compatible with existing monitoring and automation utilities.
  • z/OS Connect instances can be clustered for availability and performance, either on the same LPAR or across LPARs.
  • z/OS Connect can take advantage of connector technology that uses System z cross-memory communication mechanisms, such as WebSphere Optimized Local Adapters, that can give it a performance boost over other access technologies.
  • The security and auditing functions in z/OS Connect are provided through Interceptors, which are callout points that can be invoked for each request and each response. It’s optional for other purposes, but the interface is documented and you can write your own interceptor code if you wish.

For users of WebSphere Application Server, the Liberty profile is available beginning in WebSphere Application Server V8.5, but is an independent application server in its installation, configuration and execution. It has a different set of characteristics, being dynamic and composable, which give it a small footprint and quick startup.

Fitting in the IBM Ecosystem

IBM provides several complementary products that can be used to further enable access to mainframe assets. What follows is a brief description of some of them, and how they fit with z/OS Connect.
DataPower
Besides their security, central governance and policy control, and workload optimization features, IBM WebSphere DataPower* appliances provide enterprise-wide integration to reduce the complexity of connecting an overwhelming combination of data formats and transport protocols. DataPower appliances already provide close integration with System z with features like offloading of XML processing and message validation or filtering.
Now you can configure DataPower appliances to call z/OS Connect APIs using REST and JSON, and benefit from the aforementioned advantages that z/OS Connect provides as a common and consistent interface running on the mainframe. All of this also fits in nicely with DataPower’s ability to provide intelligent load distribution, for example across a Liberty cluster, and integrate both distributed and mainframe platforms.
API Management
Providing standardized interfaces in the form of z/OS Connect RESTful APIs is only part of the picture. To make these assets consumable, an API management solution can be required. Powered by DataPower appliances, IBM API Management provides companies with the tools for creating, collecting, securing and socializing these APIs, including those provided by z/OS Connect. It is part of a unified enterprise solution, with an intuitive user interface, for managing the complete API lifecycle, enabling a company to realize the maximum value from their APIs.
IBM Worklight
IBM Worklight*, a comprehensive mobile enterprise application platform, specifically enables the development of mobile applications. But going beyond that, Worklight includes mobile-optimized middleware that serves as a gateway between the mobile application and back-end systems. It supports adapters for many different type of connection protocols, including a Worklight HTTP Adapter to invoke RESTful services such as those provided by z/OS Connect.
JSON Web services for IBM CICS Transaction Gateway V9.1 builds on the support introduced by the CICS Transaction Server (TS) Feature Pack for Mobile Extensions, and extends the support for mobile applications to the wider CICS family. It is also compatible with z/OS Connect, meaning the investment in the creation of CICS WS BIND files for JSON data transformation is reusable, enabling the transfer of these assets between z/OS Connect-compatible solutions. This allows for the option of using z/OS Connect to expand beyond CICS to cover a broader set of z/OS subsystems, as well as take advantage of some of the other benefits of z/OS Connect as a common interface.

IMS
The IMS Mobile Feature Pack offers a comprehensive solution and integrated tooling platform that helps discover IMS transactional assets, model and annotate asset metadata, and enable and publish those assets as services. These services can be used by mobile and cloud applications, which can securely access, manage and govern IMS assets on IBM z/OS. IMS Mobile leverages the Liberty profile and its z/OS Connect feature by supplying a service provider for IMS that plugs seamlessly into the z/OS Connect framework. IMS Mobile can supplement existing user-written mobile solutions as well as mobile solutions that use Worklight, DataPower or both.
IBM Bluemix
IBM Bluemix, a cloud offering for developers, is an example of a cloud-based system that could benefit from having z/OS Connect as its access point for back-end z/OS assets. While it is tempting to think that z/OS Connect is just for use with mobile devices, the ability to access back-end mainframe systems such as CICS and IMS through a REST/JSON interface makes the provisioning and configuration of a cloud system with this type of access in mind much easier.
How to Get z/OS Connect
To build on the theme of a common and consistent interface to the mainframe, z/OS Connect is available through a number of delivery mechanisms.
In April, IBM announced that it was adopting a continuous delivery model to provide new features and function to the WebSphere Application Server Liberty profile (ibm.co/1nMNrko). In June, z/OS Connect was one of the first optionally installable features to be available by download from the Liberty Repository for WebSphere Application Server for z/OS V8.5 licensed users, and includes a CICS service provider by default. An IMS service provider is also available for download from the Liberty Repository.
For IMS licensed users, z/OS Connect is also shipped with IMS Enterprise Suite for z/OS V3.1.1 as part of the IMS Mobile Feature Pack. As provided by IMS, z/OS Connect provides the same functionality as the z/OS Connect feature with WebSphere Application Server. It’s able to do this by embedding a version of Liberty profile for use by z/OS Connect.
Whether you choose to use the version of z/OS Connect from WebSphere Application Server V8.5 or IMS Mobile Feature Pack depends mainly on whether you have a WebSphere Application Server or IMS license.
Beginning with CICS TS for z/OS V5.1, Liberty profile is embedded and available for use with CICS transactions. IBM intends to provide z/OS Connect support shipped with CICS TS for z/OS.
There is no additional charge for z/OS Connect in these environments. It is or will be supplied as part of the license entitlement to WebSphere Application Server for z/OS, CICS or IMS. Once you have z/OS Connect installed and configured, z/OS Connect can be used for connection to z/OS assets for mobile, cloud and web applications.

http://ibmsystemsmag.com/mainframe/administrator/performance/z-os-connect/?page=1


qual devo aprender primeiro? php,javascript,html,css?




Vai depender muito de sua dedicação mesmo.
Tente seguir essa ordem!!
HTML 5 com CSS 3 depois o JAVASCRIPT
Estas opções acima é para uma pagina que não vai precisar fazer login nem consultar nenhum banco de dados, e se o usuário apertar a tecla CTRL + U vai ver todas suas TAGS em HTML isso se vc usar o CSS e JAVASCRIPT fora da pagina HTML, 
O PHP da para fazer a mesma função do HTML e agregar TAGS em HTML no PHP e mesmo que o usuário tecle CTRL + U não vai ter acesso a suas linhas de códigos apenas nas TAGS em HTML.
Mesmo vc usando o HTML da também para agregar TAGS em PHP.
O PHP é utilizado para fazer um link com o banco de dados, no caso de fazer um login vc vai inserir o usuário e senha e o PHP vai fazer a consulta no banco de dado para verificar os dados inseridos e vai dar um retorno.

Bem como eu disse vai depender muito da sua dedicação e seu objetivo no aprendizado e para qual finalidade que vc vai usar.
Nível de dificuldade.
HTML = mais fácil de aprender
CSS = fácil de aprender
PHP/JAVASCRIPT = no começo um pouco complicado.

O HTML e CSS com vídeo aulas no youtube vc vai aprender muito fácil, já o PHP e JAVASCRIPT vai te dar um pouco de dor de cabeça no inicio mais depois vc vai tirar de letra. Basta praticar bastante todos os dias.

========================================================================

Seguiria (e segui quando estava aprendendo) essa ordem:

  1. html
  2. css
  3. javascript (puro, sem jQuery, angularJS, etc)
  4. http (o básico: tipos de requisições, códigos de erro, cabeçalhos, etc)
  5. php (puro sem frameworks)

Por que inclui o http na lista? Bom, das tecnologias citadas, é extremamente importante saber que algumas rodam no lado cliente (html, css e js) e outras do lado servidor (php, java, python, ruby, etc) e o http é o canal de comunicação entre esses dois ambientes, portanto, torna-se indispensável seu aprendizado, já que você usará muito get, post, headers, etc e usá-los sem ter conhecimento básico prévio pode ser perigoso.

http://www.hardware.com.br/comunidade/devo-aprender/1376528/

quarta-feira, 8 de novembro de 2017

JSON vs XML


Both JSON and XML can be used to receive data from a web server.

The following JSON and XML examples both defines an employees object, with an array of 3 employees:

JSON Example

{"employees":[
    { "firstName":"John""lastName":"Doe" },
    { "firstName":"Anna""lastName":"Smith" },
    { "firstName":"Peter""lastName":"Jones" }
]}

XML Example

<employees>
    <employee>
        <firstName>John</firstName> <lastName>Doe</lastName>
    </employee>
    <employee>
        <firstName>Anna</firstName> <lastName>Smith</lastName>
    </employee>
    <employee>
        <firstName>Peter</firstName> <lastName>Jones</lastName>
    </employee>
</employees>

 JSON is Like XML Because

  • Both JSON and XML are "self describing" (human readable)
  • Both JSON and XML are hierarchical (values within values)
  • Both JSON and XML can be parsed and used by lots of programming languages
  • Both JSON and XML can be fetched with an XMLHttpRequest

JSON is Unlike XML Because

  • JSON doesn't use end tag
  • JSON is shorter
  • JSON is quicker to read and write
  • JSON can use arrays
The biggest difference is:
 XML has to be parsed with an XML parser. JSON can be parsed by a standard JavaScript function.

Why JSON is Better Than XML

XML is much more difficult to parse than JSON.
JSON is parsed into a ready-to-use JavaScript object.
For AJAX applications, JSON is faster and easier than XML:
Using XML
  • Fetch an XML document
  • Use the XML DOM to loop through the document
  • Extract values and store in variables
Using JSON
  • Fetch a JSON string
  • JSON.Parse the JSON string
https://www.w3schools.com/js/js_json_xml.asp

XML basics for new users

An introduction to proper markup
Comments
 
2
XML stands for Extensible Markup Language, with the markup bit being the key. You can create content and mark it up with delimiting tags, making each word, phrase, or chunk into identifiable, sortable information. The files, or document instances, you create consist of elements (tags) and content, and the elements help the documents to be understood fairly well when read from printouts or even processed electronically. The more descriptive the elements, the more a document's parts can be identified. From the early days of markup to today, one advantage of tagging content is that if a computer system is lost, the data in print can still be understood from its tags.
Markup languages evolved from early, private company and government forms into Standard Generalized Markup Language (SGML), Hypertext Markup Language (HTML), and eventually into XML. SGML can seem complex, and HTML (which was really just an element set) was just not powerful enough to identify information. XML is designed as an easy-to-use and easy-to-extend markup language.
With XML, you can create your own elements, giving you the freedom to precisely represent your pieces of information. Rather than treating your documents as headings and paragraphs, you can identify each part within the document. For efficiency, you'll want to define a finite list of your elements and stick to them. (You can define your elements in a Document Type Definition (DTD) or in a schema, which I will discuss briefly later.) As you start out and get used to XML, feel free to experiment with element names as you build practice files.

Building XML

As I mentioned, your XML files will consist of content plus markup. You place much of your content in elements by surrounding your content with tags. For example, suppose you need to create an XML cookbook. You have a recipe named Ice Cream Sundae to prepare in XML. To mark up the recipe name, you enclose that text in your element by placing the beginning tag before your text and the ending tag after your text. You might call the element recipename. To mark the beginning tag of the element, place the element's name inside angle brackets (<>) like this: <recipename>. Then, type your text Ice Cream Sundae. After the text, enter the element's ending tag, which is the element's name inside angle brackets plus an ending forward slash (/) before the element's name, like this: </recipename>. These tags form an element, into which you can enter content or even other elements.
You can create element names for individual documents or for document sets. You can craft the rules for how the elements fit together based on your specific needs. You can be very specific or keep element names more generic. You can create rules for what each element is allowed to contain and make these rules strict, lax, or something in between. Just be sure to create elements that identify the parts of your documents that you feel are important.

Start your XML file

The first line of your XML document might be an XML declaration. This optional part of the file identifies it as an XML file, which can help tools and humans identify the file as XML rather than SGML or some other markup. The declaration can be written simply as <?xml?> or include the XML version (<?xml version="1.0"?>) or even the character encoding, such as <?xml version="1.0" encoding="utf-8"?> for Unicode. Because this declaration must be first in the file, if you plan to combine smaller XML files into a larger file, you might want to omit this optional information.

Create your root element

The root element's beginning and end tags surround your XML document's content. Only one root element is in the file, and you need this "wrapper" to contain it all. Listing 1 shows a truncated portion of the example I use here with a root element named <recipe>. (See Download for the full XML file.)
Listing 1. The root element
1
2
3
<?xml version="1.0" encoding="UTF-8"?>
<recipe>
</recipe>
As you build your document, your content and additional tags will go between <recipe> and </recipe>.

Name your elements

So far, you have <recipe> as your root element. With XML, you choose the names for your elements, then define the corresponding DTD or schema based on those names. The names you create can contain alphabetic characters, numbers, and special characters such as underscores (_). Here are a few things to note about your naming:
  • Spaces are not allowed in the element names.
  • Names must begin with an alphabetic character, not a number or symbol. (After this first character, you can use any combination of letters, numbers and the allowed symbols.)
  • Case does not matter, but be consistent to avoid confusion.
Building on the prior example, if you add an element named<recipename>, it will have a beginning tag <recipename> and a corresponding end tag </recipename>.
Listing 2. More elements
1
2
3
4
5
<?xml version="1.0" encoding="UTF-8"?>
<recipe>
<recipename>Ice Cream Sundae</recipename>
<preptime>5 minutes</preptime>
</recipe>
An XML document can have some empty tags that do not have anything inside and can be expressed as a single tag instead of as a set of beginning and end tags. To use an HTML-like example, you might have <img src="mylogo.gif"> as a stand-alone element. It doesn't contain any child elements or text, so it is an empty element and you can express it as <img src="mylogo.gif" /> (finished off with a space and the familiar ending slash).

Nest the elements

Nesting is the placement of elements inside other elements. These new elements are called childelements, and the elements that enclose them are their parent elements. Several elements are nested inside the <recipe> root element, as in Listing 3. These nested child items include <recipename><ingredlist>, and <preptime>. Inside the <ingredlist> element are multiple occurrences of its own child element, <listitem>. Nesting can be many levels deep in an XML document.
A common syntax error is improper nesting of parent and child elements. Any child element must be completely enclosed between the starting and end tags of its parent element. Sibling elements must each end before the next sibling begins.
The code in Listing 3 shows proper nesting. The tags begin and end without intermingling with other tags.
Listing 3. Properly nested XML elements
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?xml version="1.0" encoding="UTF-8"?>
<recipe>
<recipename>Ice Cream Sundae</recipename>
<ingredlist>
<listitem>
<quantity>3</quantity>
<itemdescription>chocolate syrup or chocolate fudge</itemdescription>
</listitem>
<listitem>
<quantity>1</quantity>
<itemdescription>nuts</itemdescription>
</listitem>
<listitem>
<quantity>1</quantity>
<itemdescription>cherry</itemdescription>
</listitem>
</ingredlist>
<preptime>5 minutes</preptime>
</recipe>

Add attributes

Attributes are sometimes added to elements. Attributes consist of a name-value pair, with the value in double quotation marks ("), thus: type="dessert". Attributes provide a way to store additional information each time you use an element, varying the attribute value as needed from one instance of an element to another within the same document.
You type the attribute—or even multiple attributes—within the starting tag of an element: <recipe type="dessert">. If you add multiple attributes, separate them with spaces: <recipename cuisine="american" servings="1">Listing 4 shows the XML file as it currently stands.
Listing 4. The current XML file with elements and attributes
1
2
3
4
5
<?xml version="1.0" encoding="UTF-8"?>
<recipe type="dessert">
<recipename cuisine="american" servings="1">Ice Cream Sundae</recipename>
<preptime>5 minutes</preptime>
</recipe>
You can use as few or as many attributes as you feel you need. Consider the details you might add to your documents. Attributes are especially helpful if documents will be sorted—for example, by type of recipe. Attribute names can include the same characters as element names, with similar rules for omitting spaces and starting names with alphabetic characters.

Well-formed versus valid XML

If you follow the rules outlined in your structure, you can easily produce well-formed XML. Well-formed XML is XML that follows all the rules of XML: proper element naming, nesting, attribute naming, and so on.
Depending on what you do with your XML, you might work with well-formed XML. But consider the aforementioned example of sorting by recipe type. You need to ensure that every <recipe> element contains the type attribute in order to sort recipes. Being able to properly validate and ensure that this attribute’s value is always present can be invaluable (no pun intended).
Validation is checking your document's structure against rules for your elements and how you defined child elements for each parent element. You define these rules in a Document Type Definition (DTD) or in a schema. This validation requires you to create your DTD or schema, and then reference the DTD or schema file within your XML files.
To enable validation, you include the document type (DOCTYPE) in your XML documents near the top. This line refers to the DTD or schema (your list of elements and rules) to be used to validate that document. For example, your DOCTYPE might read something like Listing 5.
Listing 5. DOCTYPE
1
<!DOCTYPE MyDocs SYSTEM "filename.dtd">
This example assumes that your element list file is named filename.dtd and resides on your computer (SYSTEM versus PUBLIC if pointing to a public file location).

Using entities

Entities can be phrases of text or special characters. They can point internally or externally. Entities must be declared and expressed properly to avoid errors and to ensure proper display.
You cannot typed special characters directly into your content. To use a symbol in your text, you must set it up as an entity using its character code. You can set up phrases such as a company name as an entity, then type the entity throughout your content. To set up an entity, create a name for it, and type it within your content, starting with an ampersand (&) and ending with a semicolon (;)—for example, &coname; (or whatever you name it). You then enter code within your DOCTYPE inside square brackets ([]), as in Listing 6. This code identifies the text that stands in for the entity.
Listing 6. ENTITY
1
2
3
<!DOCTYPE MyDocs SYSTEM "filename.dtd" [ <!ENTITY coname "Rabid Turtle
Industries"
]>
Using entities might help you avoid typing the same phrase or information repeatedly. It can also make it easier to adjust the text—perhaps if the company name changes—in many places with a simple adjustment in the entity definition.

Avoiding errors

As you learn to create your XML files, open them in an XML editor to check for well-formedness and confirm that you're following the rules of XML. If, for example, you have Windows® Internet Explorer®, you can open your XML file in the browser. If it displays your elements, attributes, and content, then the XML is well formed. If instead errors are displayed, you likely have a syntax error and need to review your document carefully for typos or missing tags and punctuation.
As mentioned in Nest the elements, an element that contains another element is the parent of that contained element. In the example below, <recipe> is the root element and contains the full content of the file. This parent element, <recipe>, contains child elements <recipename><ingredlist>,<directions>, and several others. This structure makes <recipename><ingredlist>, and<directions> siblings. Remember to nest your sibling elements properly, as well. Listing 7 shows well-formed and properly nested XML.
Listing 7. Well-formed XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
<?xml version="1.0" encoding="UTF-8"?>
<recipe type="dessert">
<recipename cuisine="american" servings="1">Ice Cream Sundae</recipename>
<ingredlist>
<listitem><quantity units="cups">0.5</quantity>
<itemdescription>vanilla ice cream</itemdescription></listitem>
<listitem><quantity units="tablespoons">3</quantity>
<itemdescription>chocolate syrup or chocolate fudge</itemdescription></listitem>
<listitem><quantity units="tablespoons">1</quantity>
<itemdescription>nuts</itemdescription></listitem>
<listitem><quantity units="each">1</quantity>
<itemdescription>cherry</itemdescription></listitem>
</ingredlist>
<utensils>
<listitem><quantity units="each">1</quantity>
<utensilname>bowl</utensilname></listitem>
<listitem><quantity units="each">1</quantity>
<utensilname>spoons</utensilname></listitem>
<listitem><quantity units="each">1</quantity>
<utensilname>ice cream scoop</utensilname></listitem>
</utensils>
<directions>
<step>Using ice cream scoop, place vanilla ice cream into bowl.</step>
<step>Drizzle chocolate syrup or chocolate fudge over the ice cream.</step>
<step>Sprinkle nuts over the mound of chocolate and ice cream.</step>
<step>Place cherry on top of mound with stem pointing upward.</step>
<step>Serve.</step>
</directions>
<variations>
<option>Replace nuts with raisins.</option>
<option>Use chocolate ice cream instead of vanilla ice cream.</option>
</variations>
<preptime>5 minutes</preptime>
</recipe>
Note: The line breaks make it easier for you to read your code and do not affect the XML.
You might wish to experiment with your test files, and move the end tags and beginning tags, to become familiar with the resulting error messages.

Reviewing XML

In Figure 1, your elements show up clearly when viewed within Internet Explorer. Beginning and end tags surround your content. Small plus (+) and minus (-) symbols are available next to parent elements so you can collapse all elements nested inside them (their descendants).
Figure 1. A sample XML instance (file) with some siblings collapsed
Sample XML instance with siblings collapsed

Wrapping up

Beyond a few simple rules, you have flexibility in designing your XML elements and attributes. XML’s rules are not difficult. Typing an XML document is also not difficult. What is difficult is figuring out what you need from your documents in terms of sortability or searchability, then designing elements and attributes to meet your needs.
When you have a good idea of your goals and how to mark up your content, you can build efficient elements and attributes. From that point, careful tagging is all you need to create well-formed and valid XML.

Downloadable resources

Related topics

  • XML technical library: See the developerWorks XML Zone for a wide range of technical articles and tips, tutorialsstandards, and IBM Redbooks.
  • XML topic on Wikipedia: Learn more about XML.
  • XML Tutorials at W3 Schools: Expand and test your skills from basic XML through JavaScript and other advanced topics.
  • XML specification from the World Wide Web Consortium: Read more about this flexible text format that works for large-scale electronic publishing as well as the exchange of a wide variety of data on the Web and elsewhere.
  • Introduction to XML (Doug Tidwell, developerWorks, August 2002): Further explore what XML is, why it was developed, and how it shapes electronic commerce in this tutorial. Also, cover various important XML programming interfaces and standards, plus two case studies that show how companies solve business problems with XML.
  • IBM trial software for product evaluation: Build your next project with trial software available for download directly from developerWorks, including application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  • developerWorks podcasts: Listen to interesting interviews and discussions for software developers.
https://www.ibm.com/developerworks/library/x-newxml/