millatfacebook

Jejaring sosial yang dibuat oleh6 orang  muslim dari Pakistan. Diluncurkan 26 mei 2010. Situs ini mencoba memberikan pilihan alternatif penggunaan jejaring sosial. Coba ah!

UTA method

The UTA method was originally proposed by E.Jacquet-Lagrèze and J.Siskos
in 1982. It has gained popularity thanks to implementation called PREFCALC,
written by E.Jacquet-Lagrèze. Then, it was improved and modified by several authors
(see the References at the end of the Manual).
UTA+ was written in Borland C++ 3.1 with Object Windows Library, at the
Poznan University of Technology, Poland.
The UTA+ software is the latest implementation of the UTA method in
Windows environment. It summarizes all important contributions made by other
authors and offers some new possibilities, in particular, a “compensation” of
marginal utility functions controlled by the user and the use of preference intensities
in addition to the ranking defined by the user.
The method can be used to solve the problems of multicriteria choice and
ranking on a set A of alternatives. It constructs an additive utility function nom a
preference weak order defined by the user on a subset A’ of reference alternatives.
The construction, based on a principle of ordinal regression, consists of solving a
small LP problem. The software proposes marginal utility functions in piecewise
linear form as compatible as possible with the given weak order. It allows the user to
modify interactively the marginal utility functions within limits following from a
sensitivity analysis of the ordinal regression problem. For these modifications, the
user is helped by a friendly graphical interface.
The utility function accepted by the user serves then to define a weak order on
the whole set A of alternatives.
The UTA+ software is composed of four main modules:
I – Problem editing, including definition of criteria and alternatives, and of the most
and least preferred values of criteria.
II – Definition of a ranking ( preference weak order ) on a small set of reference
alternatives.
III – Ordinal regression, including specification of required properties of the utility
function prior to application of the solution procedure.
IV – Display and modification of the marginal utility functions and application of the
accepted utility function for the calculation of the final ranking of alternatives

Pengindeksan dan Seleksi Fitur

Sistem temu kembali yang memiliki kinerja baik sangat diperlukan terutama untuk menghadapi perkembangan yang sangat pesat dari dokumen khususnya dokumen berbasis teks seperti laporan penelitian, artikel, skripsi, tesis, dan sebagainya. Sistem temu-kembali informasi adalah suatu sistem yang mengolah data berbasis dokumen atau teks dalam jumlah besar dan memberikan dokumen-dokumen sesuai dengan query yang diberikan pemakai.
Hal-hal yang dilakukan oleh suatu sistem temu-kembali informasi diantaranya adalah sebagai berikut :
1. Mengolah record-record berupa teks atau dokumen, yaitu mengidentifikasikan sejumlah istilah yang dianggap mewakili isi dokumen.
2. Mengidentifikasikan permintaan informasi (information request / query)
3. Menentukan dan mengambil informasi atau dokumen yang sesuai dengan permintaan pemakai.
Tahapan pertama tersebut dikenal dengan pengindeksan. Pengindeksan merupakan cara untuk mendapatkan istilah-istilah yang dianggap mewakili isi dari dokumen.

Pengindeksan dapat dilakukan secara manual atau otomatis. Jika dengan cara manual, dibutuhkan campur tangan seorang manusia yang dikenal dengan indexer yang bertugas untuk memlilih istilah-istilah yang terdapat pada dokumen untuk dijadikan index term yang merepresentasikan dokumen tersebut. Sedangkan pada pengindeksan yang dilakukan secara otomatis, pemilihan term index dilakukan secara otomatis menggunakan program komputer .
Ketepatan pemilihan istilah merupakan isu yang menentukan kinerja dari sistem yang dihasilkan. Pada dasarnya setiap kata yang muncul pada dokumen dapat dijadikan index term. Namun jika semua kata dijadikan index term, disamping ukuran indeks menjadi besar, belum tentu kata-kata tersebut merepresentasikan isi dokumen .
Secara umum, istilah-istilah yang sering muncul pada banyak dokumen tidak layak dijadikan indeks, seperti kata sambung dan, atau, juga, dsb. Kata-kata tersebut tidak layak jika dijadikan sebagai index term karena :
- Mereka muncul sangat sering pada dokumen, bahkan semua dokumen memiliki kata-kata tersebut.
- Kata-kata tersebut tidak menggambarkan isi dari dokumen yang bersangkutan.
Satu lagi jenis kata yang juga kurang baik dijadikan indeks, adalah kata-kata yang jarang muncul, muncul hanya sekali atau dua kali pada dokumen tertentu . Jika kata-kata seperti ini dijadikan indeks maka sangat sedikit dokumen yang akan terambil. Apalagi jika kata-kata tersebut dijadikan dalam satu query secara bersamaan maka kemungkinan tidak ada dokumen yang terambil.
Dengan melihat kondisi tersebut diatas maka disarankan menggunakan dua threshold (nilai ambang), yaitu untuk menentukan batas atas dimana nilai frekuensi tertinggi dari istilah yang diperbolehkan dan batas bawah untuk menentukan nilai frekuensi terendah. Proses ini disebut dengan seleksi fitur .
Diharapkan dengan seleksi fitur dapat mengurangi istilah-istilah yang tidak berpotensi menjadi indeks, sekaligus mengurangi ukuran indeks sehingga mempercepat proses pencarian. Namun diharapkan dengan adanya pengurangan istilah tersebut tidak mengurangi kinerja sistem, atau paling tidak sama dengan kinerja sistem tanpa seleksi fitur. Sehingga dalam penelitian ini dilakukan uji coba untuk melihat sejauh mana efektifitas pengurangan index-term pada ketiga strategi diatas terhadap kinerja sistem temu-kembali informasi.

Pengujian Ontology dengan pOWL

Ontology yang sudah dihasilkan dapat diuji kompatibelitasnya dengan menggunakan pOWL. pOWL merupakan aplikasi berbasis web yang digunakan untuk kolaborasi pembuatan web semantik. pOWL memiliki kemampuan SQL query dan berbasis pada API untuk menangani layer RDF dan RDFS serta OWL.

Jena Ontology API

In this section I will give a general introduction to the the Jena2 ontology API. I’ll also describe a range of common user tasks. I won’t go into all of the many details of the API here: you should expect to refer to the Jena2 Javadoc to get full details of the capabilities of the API. Feedback, (via the jena-dev support list) is welcomed.

Prerequisites

I will assume that you have a basic familiarity with RDF and with Jena. There are many other Jena help documents you can read for background on these topics. There is also a Jena programming tutorial you can follow through.

Jena is a programming toolkit, using the Java programming language. While there are a few command-line tools to help you perform some key tasks using Jena, mostly you use Jena by writing Java programs. The examples in this document will be primarily code samples.

I also won’t be explaining the OWL or RDFS ontology languages in much detail in this document. You should expect to refer to supporting documentation for details on those languages, for example the W3C OWL document index.

Note: At the time of writing, work on OWL version 1.1 is still underway. No decision has yet been made about when Jena will support the new OWL 1.1 features. I will only use OWL 1.0 features in this document.

Overview

The section of the manual is broken into a number of sections. You do not need to read them in sequence, though later sections may refer to concepts and techniques introduced in earlier sections. The sections are:

  1. Overview
  2. General concepts
  3. Running example: the ESWC ontology
  4. Creating ontology models
  5. Compound ontology documents and imports processing
  6. The generic ontology type: OntResource
  7. Ontology classes and basic class expressions
  8. Ontology properties
  9. More complex class expressions
  10. Instances or individuals
  11. Ontology meta-data
  12. Ontology inference: overview
  13. Working with DAML+OIL ontologies
  14. Working with persistent ontologies
  15. Experimental ontology tools
  16. Common ontology application problems and sample programs

Lanjut membaca

An Introduction to RDF and the Jena RDF API

Preface

This is a tutorial introduction to both W3C’s Resource Description Framework (RDF) and Jena, a Java API for RDF. It is written for the programmer who is unfamiliar with RDF and who learns best by prototyping, or, for other reasons, wishes to move quickly to implementation. Some familiarity with both XML and Java is assumed.

Implementing too quickly, without first understanding the RDF data model, leads to frustration and disappointment. Yet studying the data model alone is dry stuff and often leads to tortuous metaphysical conundrums. It is better to approach understanding both the data model and how to use it in parallel. Learn a bit of the data model and try it out. Then learn a bit more and try that out. Then the theory informs the practice and the practice the theory. The data model is quite simple, so this approach does not take long.

RDF has an XML syntax and many who are familiar with XML will think of RDF in terms of that syntax. This is mistake. RDF should be understood in terms of its data model. RDF data can be represented in XML, but understanding the syntax is secondary to understanding the data model.

An implementation of the Jena API, including the working source code for all the examples used in this tutorial can be downloaded from http://jena.sourceforge.net/downloads.html. Lanjut membaca

Tabu search

Tabu search (TS) digunakan untuk menyelesaikan permasalahan kombinatorial untuk problem optimasi. Tujuan dari metode ini adalah untuk mendapatkan ruang solusi tanpa terjebak dalam local optima dan tanpa berputar-putar terlalu lama dengan algoritma. TS menggunakan pendekatan iterasi yang dimulai dari initial solution (feasible atau tidak) dan mencoba untuk memperbaikinya sampai tercapai kondisi stop tertentu. Pada setiap iterasi, hasil terbaik dari nilai tetangga (neigborhood) dipilih untuk mendapatkan nilai solusi berikutnya. Attribut dari nilai terbaik disimpan di list tabu T, dan sisanya disimpan pada sisa |T|, dengan |T| adalah ukuran list tabu. Informasi yang didapat dari list tabu digunakan untuk melakukan restriksi pengulangan tertentu.
Pada penelitian ini, tabu search di hibridkan ke algoritma CDS, sama dengan yang dilakukan pada algoritma genetika. Urutan dari nilai tetangga (neighborhood) N didapat dengan melakukan permutasi posisi dari pasangan job Ji dan Jj, yang berada di posisi i dan j. Pasangan (Ji,i) dan (Jj,j) diinputkan ke tabu list T sehingga job Ji (berurut Jj) tidak akan kembali ke posisi i (berurut j) selama iterasi |T|. Ukuran dari list tabu di samakan dengan jumlah job. Tabu search dihentikan setelah 1000 iterasi.

Simulated Annealing

Ide dasar simulated annealing terbentuk dari pemrosesan logam. Annealing (memanaskan kemudian mendinginkan) dalam pemrosesan logam ini adalah suatu proses bagaimana membuat bentuk cair berangsur-angsur menjadi bentuk yang lebih padat seiring dengan penurunan temperatur. Simulated annealing biasanya digunakan untuk penyelesaian masalah yang mana perubahan keadaan dari suatu kondisi ke kondisi yang lainnya  membutuhkan ruang yang sangat luas, misalkan perubahan gerakan dengan menggunakan permutasi pada masalah Travelling Salesman Problem. Pada simulated annealing, ada 3 parameter yang sangat menentukan, yaitu: tetangga, gain, temperatur, pembangkitan bilangan random. Tetangga akan sangat berperan dalam membentuk perubahan pada solusi sekarang. Pembangkitan bilangan random akan berimplikasi adanya probabilitas.

Algoritma Simulated Annealing
Algoritma Simulated Annealing adalah sebagai berikut :
a. Evaluasi keadaan awal. Jika keadaan awal merupakan tujuan, maka  pencarian berhasil dan KELUAR. Jika tidak demikian, lanjutkan dengan menetapkan keadaan awal sebagai kondisi sekarang.
b. Inisialisasi BEST_SO_FAR untuk keadaan sekarang.
c. Inisialisasi T sesuai dengan annealing schedule.
d. Kerjakan hingga solusi ditemukan atau sudah tidak ada operator baru lagi akan diaplikasikan ke kondisi sekarang.
1. Gunakan operator yang belum pernah digunakan tersebut untuk menghasilkan kondisi baru.
2. Evaluasi kondisi yang baru dengan menghitung:
E = nilai sekarang – nilai keadaan baru.

  • Jika kondisi baru merupakan tujuan, maka pencarian berhasil dan KELUAR.
  • Jika bukan tujuan, namun memiliki nilai yang lebih baik daripada kondisi sekarang, maka tetapkan kondisi baru sebagai kondisi sekarang. Demikian pula tetapkan BEST_SO_FAR untuk kondisi yang baru tadi.
  • Jika nilai kondisi baru tidak lebih baik dari kondisi sekarang, maka tetapkan
  • kondisi baru sebagai kondisi sekarang dengan probabilitas:

p’ eE / T
Langkah ini biasanya dikerjakan dengan membangkitkan suatu bilangan random r pada range [0 1]. Jika r < p’, maka perubahan kondisi baru menjadi kondisi sekarang diperbolehkan. Namun jika tidak demikian, maka tidak akan dikerjakan apapun.
3. Perbaiki T sesuai dengan annealing scheduling.
e. BEST_SO_FAR adalah jawaban yang dimaksudkan.

Operator untuk Penyelesaian TSP dengan Simulated Annealing
Ada beberapa operator yang bisa digunakan untuk penyelesaian TSP dengan
Simulated Annealing. Berikut adalah salah satu contoh operator untuk menentukan jalur. Misalkan jumlah kota yang akan dikunjungi adalah NC.
a. Kota-kota disimpan pada larik L.
b. Kita bangkitkan 2 bilangan random antara 1 sampai NC, misalkan kedua bilangan itu adalah N1 dan N2 dengan N1 < N2.
c. Depan = L(1) sampai L(N1-1).
d. Tengah = L(N1) sampai L(N2).
e. Belakang = L(N2+1) sampai L(NC).
f. Bangkitkan bilangan random r, apabila r < 0,5; maka:
o DepanBaru = Depan.
o TengahBaru = Tengah dengan urutan dibalik.
o BelakangBaru = Belakang.
o Lbaru = [DepanBaru TengahBaru BelakangBaru]
g. Jika r = 0,5; maka kerjakan:
o Sementara = [Depan Belakang], misalkan memiliki M elemen.
o Bangkitkan bilangan random r dengan nilai antara 1 sampai M.
o DepanBaru = Sementara(1:r).
o TengahBaru = Tengah.
o BelakangBaru = Sementara(r+1:M).
o Lbaru = [DepanBaru TengahBaru BelakangBaru]

Metodologi Penelitian
Penelitian dilakukan melalui langkah-langkah sebagai berikut:
a. Menentukan variabel-variabel input properti sistem, yang meliputi: jumlah mesin, dimensi setiap mesin (panjang dan lebar), mesin-mesin yang digunakan pada setiap part, volume produksi, dan ukuran batch;
b. Merepresentasikan solusi dengan analogi TSP.
c. Menentukan parameter-parameter Simulated Annealing, yang meliputi: maksimum perulangan, maksimum sukses, dan penurunan temperatur.
d. Mengaplikasikan simulated annealing untuk mencari tata letak mesin dengan biaya minimum. Lanjut membaca

XML Validation

XML with correct syntax is “Well Formed” XML.

XML validated against a DTD is “Valid” XML.


Well Formed XML Documents

A “Well Formed” XML document has correct XML syntax.

The syntax rules were described in the previous chapters:

  • XML documents must have a root element
  • XML elements must have a closing tag
  • XML tags are case sensitive
  • XML elements must be properly nested
  • XML attribute values must be quoted
<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don’t forget me this weekend!</body>
</note>

Valid XML Documents

A “Valid” XML document is a “Well Formed” XML document, which also conforms to the rules of a Document Type Definition (DTD):

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<!DOCTYPE note SYSTEM “Note.dtd”>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don’t forget me this weekend!</body>
</note>

The DOCTYPE declaration in the example above, is a reference to an external DTD file. The content of the file is shown in the paragraph below.


XML DTD

The purpose of a DTD is to define the structure of an XML document. It defines the structure with a list of legal elements:

<!DOCTYPE note
[
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>

If you want to study DTD, you will find our DTD tutorial on our homepage.


XML Schema

W3C supports an XML-based alternative to DTD, called XML Schema:

<xs:element name=”note”>

<xs:complexType>
<xs:sequence>
<xs:element name=”to” type=”xs:string”/>
<xs:element name=”from” type=”xs:string”/>
<xs:element name=”heading” type=”xs:string”/>
<xs:element name=”body” type=”xs:string”/>
</xs:sequence>
</xs:complexType>

</xs:element>

If you want to study XML Schema, you will find our Schema tutorial on our homepage.


A General XML Validator

To help you check the syntax of your XML files, we have created an XML validator to syntax-check your XML.

XML Attributes

XML elements can have attributes in the start tag, just like HTML.

Attributes provide additional information about elements.


XML Attributes

From HTML you will remember this: <img src=”computer.gif”>. The “src” attribute provides additional information about the <img> element.

In HTML (and in XML) attributes provide additional information about elements:

<img src=”computer.gif”>
<a href=”demo.asp”>

Attributes often provide information that is not a part of the data. In the example below, the file type is irrelevant to the data, but important to the software that wants to manipulate the element:

<file type=”gif”>computer.gif</file>

XML Attributes Must be Quoted

Attribute values must always be enclosed in quotes, but either single or double quotes can be used. For a person’s sex, the person tag can be written like this:

<person sex=”female”>

or like this:

<person sex=’female’>

If the attribute value itself contains double quotes you can use single quotes, like in this example:

<gangster name=’George “Shotgun” Ziegler’>

or you can use character entities:

<gangster name=”George &quot;Shotgun&quot; Ziegler”>

XML Elements vs. Attributes

Take a look at these examples:

<person sex=”female”>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
<person>
<sex>female</sex>
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>

In the first example sex is an attribute. In the last, sex is an element. Both examples provide the same information.

There are no rules about when to use attributes and when to use elements. Attributes are handy in HTML. In XML my advice is to avoid them. Use elements instead.


My Favorite Way

The following three XML documents contain exactly the same information:

A date attribute is used in the first example:

<note date=”10/01/2008″>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don’t forget me this weekend!</body>
</note>

A date element is used in the second example:

<note>
<date>10/01/2008</date>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don’t forget me this weekend!</body>
</note>

An expanded date element is used in the third: (THIS IS MY FAVORITE):

<note>
<date>
<day>10</day>
<month>01</month>
<year>2008</year>
</date>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don’t forget me this weekend!</body>
</note>

Avoid XML Attributes?

Some of the problems with using attributes are:

  • attributes cannot contain multiple values (elements can)
  • attributes cannot contain tree structures (elements can)
  • attributes are not easily expandable (for future changes)

Attributes are difficult to read and maintain. Use elements for data. Use attributes for information that is not relevant to the data.

Don’t end up like this:

<note day=”10″ month=”01″ year=”2008″
to=”Tove” from=”Jani” heading=”Reminder”
body=”Don’t forget me this weekend!”>
</note>

XML Attributes for Metadata

Sometimes ID references are assigned to elements. These IDs can be used to identify XML elements in much the same way as the ID attribute in HTML. This example demonstrates this:

<messages>
<note id=”501″>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don’t forget me this weekend!</body>
</note>
<note id=”502″>
<to>Jani</to>
<from>Tove</from>
<heading>Re: Reminder</heading>
<body>I will not</body>
</note>
</messages>

The ID above is just an identifier, to identify the different notes. It is not a part of the note itself.

What I’m trying to say here is that metadata (data about data) should be stored as attributes, and that data itself should be stored as elements.

XML Elements

An XML document contains XML Elements.


What is an XML Element?

An XML element is everything from (including) the element’s start tag to (including) the element’s end tag.

An element can contain other elements, simple text or a mixture of both. Elements can also have attributes.

<bookstore>
<book category=”CHILDREN”>
<title>Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
<price>29.99</price>
</book>
<book category=”WEB”>
<title>Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
<price>39.95</price>
</book>
</bookstore>

In the example above, <bookstore> and <book> have element contents, because they contain other elements. <author> has text content because it contains text.

In the example above only <book> has an attribute (category=”CHILDREN”).


XML Naming Rules

XML elements must follow these naming rules:

  • Names can contain letters, numbers, and other characters
  • Names cannot start with a number or punctuation character
  • Names cannot start with the letters xml (or XML, or Xml, etc)
  • Names cannot contain spaces

Any name can be used, no words are reserved.


Best Naming Practices

Make names descriptive. Names with an underscore separator are nice: <first_name>, <last_name>.

Names should be short and simple, like this: <book_title> not like this: <the_title_of_the_book>.

Avoid “-” characters. If you name something “first-name,” some software may think you want to subtract name from first.

Avoid “.” characters. If you name something “first.name,” some software may think that “name” is a property of the object “first.”

Avoid “:” characters. Colons are reserved to be used for something called namespaces (more later).

XML documents often have a corresponding database. A good practice is to use the naming rules of your database for the elements in the XML documents.

Non-English letters like éòá are perfectly legal in XML, but watch out for problems if your software vendor doesn’t support them.


XML Elements are Extensible

XML elements can be extended to carry more information.

Look at the following XML example:

<note>
<to>Tove</to>
<from>Jani</from>
<body>Don’t forget me this weekend!</body>
</note>

Let’s imagine that we created an application that extracted the <to>, <from>, and <body> elements from the XML document to produce this output:

MESSAGETo: Tove
From: Jani

Don’t forget me this weekend!

Imagine that the author of the XML document added some extra information to it:

<note>
<date>2008-01-10</date>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don’t forget me this weekend!</body>
</note>

Should the application break or crash?

No. The application should still be able to find the <to>, <from>, and <body> elements in the XML document and produce the same output.

One of the beauties of XML, is that it can often be extended without breaking applications.

XML Syntax Rules

The syntax rules of XML are very simple and logical. The rules are easy to learn, and easy to use.


All XML Elements Must Have a Closing Tag

In HTML, you will often see elements that don’t have a closing tag:

<p>This is a paragraph
<p>This is another paragraph

In XML, it is illegal to omit the closing tag. All elements must have a closing tag:

<p>This is a paragraph</p>
<p>This is another paragraph</p>

Note: You might have noticed from the previous example that the XML declaration did not have a closing tag. This is not an error. The declaration is not a part of the XML document itself, and it has no closing tag.


XML Tags are Case Sensitive

XML elements are defined using XML tags.

XML tags are case sensitive. With XML, the tag <Letter> is different from the tag <letter>.

Opening and closing tags must be written with the same case:

<Message>This is incorrect</message>
<message>This is correct</message>

Note: “Opening and closing tags” are often referred to as “Start and end tags”. Use whatever you prefer. It is exactly the same thing.


XML Elements Must be Properly Nested

In HTML, you might see improperly nested elements:

<b><i>This text is bold and italic</b></i>

In XML, all elements must be properly nested within each other:

<b><i>This text is bold and italic</i></b>

In the example above, “Properly nested” simply means that since the <i> element is opened inside the <b> element, it must be closed inside the <b> element.


XML Documents Must Have a Root Element

XML documents must contain one element that is the parent of all other elements. This element is called the root element.

<root>
<child>
<subchild>…..</subchild>
</child>
</root>

XML Attribute Values Must be Quoted

XML elements can have attributes in name/value pairs just like in HTML.

In XML the attribute value must always be quoted. Study the two XML documents below. The first one is incorrect, the second is correct:

<note date=12/11/2007>
<to>Tove</to>
<from>Jani</from>
</note>
<note date=”12/11/2007″>
<to>Tove</to>
<from>Jani</from>
</note>

The error in the first document is that the date attribute in the note element is not quoted.


Entity References

Some characters have a special meaning in XML.

If you place a character like “<” inside an XML element, it will generate an error because the parser interprets it as the start of a new element.

This will generate an XML error:

<message>if salary < 1000 then</message>

To avoid this error, replace the “<” character with an entity reference:

<message>if salary &lt; 1000 then</message>

There are 5 predefined entity references in XML:

&lt; < less than
&gt; > greater than
&amp; & ampersand
&apos; apostrophe
&quot; quotation mark

Note: Only the characters “<” and “&” are strictly illegal in XML. The greater than character is legal, but it is a good habit to replace it.


Comments in XML

The syntax for writing comments in XML is similar to that of HTML.

<!– This is a comment –>


White-space is Preserved in XML

HTML truncates multiple white-space characters to one single white-space:

HTML: Hello           my name is Tove
Output: Hello my name is Tove.

With XML, the white-space in a document is not truncated.


XML Stores New Line as LF

In Windows applications, a new line is normally stored as a pair of characters: carriage return (CR) and line feed (LF). The character pair bears some resemblance to the typewriter actions of setting a new line. In Unix applications, a new line is normally stored as a LF character. Macintosh applications also use an LF to store a new line.