DTD: July 2012

Sunday 8 July 2012

EMBEDDED IMAGES

EMBEDDED IMAGES

To embed non-XML data (such as an image) into your XML document, you need to treat it as

an external unparsed entity. To declare an external unparsed entity, you use the <!ENTITY>

declaration along with the NDATA keyword.

Syntax

<!ENTITY name SYSTEM value NDATA TYPE>

You can also use public external unparsed entities by using the PUBLIC keyword along with a Formal Public Identifier (FPI):

<!ENTITY name PUBLIC FPI value NDATA TYPE>

Example

Here's an example of a private external unparsed entity. Here, we declare a new notation named "JPG" for the "image/jpeg" MIME type. Then we declare an external unparsed entity called "mt_cook_1" that refers to an image file called "mt_cook1_jpg". We then create a new attribute of type ENTITY - this means that we can now use this attribute in our XML document to refer to the unparsed external entity.

<!NOTATION JPG SYSTEM "image/jpeg">

<!ENTITY mt_cook_1 SYSTEM "mt_cook1.jpg" NDATA JPG>

<!ATTLIST mountain photo ENTITY #IMPLIED>

After declaring the external unparsed entity in our DTD (and creating an attribute of type ENTITY), we can now embed it in our XML document:

<mountains> <mountain photo="mt_cook_1">

<name>Mount Cook</name> </mountain>

<mountain> <name>Cradle Mountain</name> </mountain>

</mountains>

Embedding Multiple Images

If you need to embed multiple external unparsed entities via a single attribute, you simply give your attribute a type of ENTITIES (plural). This allows you to assign multiple images separated by a space.

Here's an example:

<!NOTATION JPG SYSTEM "image/jpeg">

<!ENTITY mt_cook_1 SYSTEM "mt_cook1.jpg" NDATA JPG>

<!ENTITY mt_cook_2 SYSTEM "mt_cook2.jpg" NDATA JPG>

<!ATTLIST mountain photo ENTITIES #IMPLIED>

Now that we've changed the "photo" attribute to type ENTITIES, we can assign multiple images to it in our XML document:

<mountains> <mountain photo="mt_cook_1 mt_cook_2">

<name>Mount Cook</name> </mountain>

<mountain> <name>Cradle Mountain</name>

</mountain></mountains>

FPI

FPI

When declaring a DTD available for public use, you need to use the PUBLIC keyword within

your DOCTYPE declaration. When you use the PUBLIC keyword, you also need to use an FPI

(which stands for Formal Public Identifier).

FPI Syntax

An FPI is made up of 4 fields, each separated by double forward slashes (//):

field 1//field 2//field 3//field 4

FPI Example

Here's a real life example of an FPI. In this case, the DTD was created by the W3C for XHTML:

-//W3C//DTD XHTML 1.0 Transitional//EN

FPI Fields

An FPI must contain the following fields:

Field	Example	Description
Separator	//	This is used to separate the different fields of the FPI.
First field	-	Indicates whether the DTD is connected to a formal standard or not. If the DTD hasn't been approved (for example, you've defined the DTD yourself), use a hypen (-). If the DTD has been approved by a nonstandards body, use a plus sign "+". If the DTD has been approved by a formal standards body this field should be a reference to the standard itself.
Second field	W3C	Holds the name of the group (or person) responsible for the DTD. The above example is maintained by the W3C, so "W3C" appears in the second field.
Third field	DTD XHTML 1.0 Transitional	Indicates the type of document that is being described. This usually contains some form of unique identifier (such as a version number).
Fourth field	EN	Specifies the language that the DTD uses. This is achieved by using the two letter identifier for the language (i.e. for english, use "EN").

FPI DOCTYPE Syntax

When using a public DTD, place the FPI between the PUBLIC keyword and the URI/URL.

<!DOCTYPE rootname PUBLIC FPI URL>

FPI DOCTYPE Example

You can see an example of an FPI in the following DOCTYPE declaration (the FPI is in bold):

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Friday 6 July 2012

MUST READ

TV Schedule DTD

<!DOCTYPE TVSCHEDULE [

<!ELEMENT TVSCHEDULE (CHANNEL+)>
<!ELEMENT CHANNEL (BANNER,DAY+)>
<!ELEMENT BANNER (#PCDATA)>
<!ELEMENT DAY (DATE,(HOLIDAY|PROGRAMSLOT+)+)>
<!ELEMENT HOLIDAY (#PCDATA)>
<!ELEMENT DATE (#PCDATA)>
<!ELEMENT PROGRAMSLOT (TIME,TITLE,DESCRIPTION?)>
<!ELEMENT TIME (#PCDATA)>
<!ELEMENT TITLE (#PCDATA)>
<!ELEMENT DESCRIPTION (#PCDATA)>

<!ATTLIST TVSCHEDULE NAME CDATA #REQUIRED>
<!ATTLIST CHANNEL CHAN CDATA #REQUIRED>
<!ATTLIST PROGRAMSLOT VTR CDATA #IMPLIED>
<!ATTLIST TITLE RATING CDATA #IMPLIED>
<!ATTLIST TITLE LANGUAGE CDATA #IMPLIED>
]>

Newspaper Article DTD

<!DOCTYPE NEWSPAPER [

<!ELEMENT NEWSPAPER (ARTICLE+)>
<!ELEMENT ARTICLE (HEADLINE,BYLINE,LEAD,BODY,NOTES)>
<!ELEMENT HEADLINE (#PCDATA)>
<!ELEMENT BYLINE (#PCDATA)>
<!ELEMENT LEAD (#PCDATA)>
<!ELEMENT BODY (#PCDATA)>
<!ELEMENT NOTES (#PCDATA)>

<!ATTLIST ARTICLE AUTHOR CDATA #REQUIRED>
<!ATTLIST ARTICLE EDITOR CDATA #IMPLIED>
<!ATTLIST ARTICLE DATE CDATA #IMPLIED>
<!ATTLIST ARTICLE EDITION CDATA #IMPLIED>

<!ENTITY NEWSPAPER "Vervet Logic Times">
<!ENTITY PUBLISHER "Vervet Logic Press">
<!ENTITY COPYRIGHT "Copyright 1998 Vervet Logic Press">

]>

Product Catalog DTD

<!DOCTYPE CATALOG [

<!ENTITY AUTHOR "John Doe">
<!ENTITY COMPANY "JD Power Tools, Inc.">
<!ENTITY EMAIL "jd@jd-tools.com">

<!ELEMENT CATALOG (PRODUCT+)>

<!ELEMENT PRODUCT
(SPECIFICATIONS+,OPTIONS?,PRICE+,NOTES?)>
<!ATTLIST PRODUCT
NAME CDATA #IMPLIED
CATEGORY (HandTool|Table|Shop-Professional) "HandTool"
PARTNUM CDATA #IMPLIED
PLANT (Pittsburgh|Milwaukee|Chicago) "Chicago"
INVENTORY (InStock|Backordered|Discontinued) "InStock">

<!ELEMENT SPECIFICATIONS (#PCDATA)>
<!ATTLIST SPECIFICATIONS
WEIGHT CDATA #IMPLIED
POWER CDATA #IMPLIED>

<!ELEMENT OPTIONS (#PCDATA)>
<!ATTLIST OPTIONS
FINISH (Metal|Polished|Matte) "Matte"
ADAPTER (Included|Optional|NotApplicable) "Included"
CASE (HardShell|Soft|NotApplicable) "HardShell">

<!ELEMENT PRICE (#PCDATA)>
<!ATTLIST PRICE
MSRP CDATA #IMPLIED
WHOLESALE CDATA #IMPLIED
STREET CDATA #IMPLIED
SHIPPING CDATA #IMPLIED>

<!ELEMENT NOTES (#PCDATA)>

]>

DTD Validation

With Internet Explorer you can validate your XML against a DTD.

Validating With the XML Parser

If you try to open an XML document, the XML Parser might generate an error. By accessing the parseError object, you can retrieve the error code, the error text, or even the line that caused the error.

hint: The load( ) method is used for files, while the loadXML( ) method is used for strings.

Example

var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async="false";
xmlDoc.validateOnParse="true";
xmlDoc.load("note_dtd_error.xml");

document.write(" Error Code: ");
document.write(xmlDoc.parseError.errorCode);
document.write(" Error Reason: ");
document.write(xmlDoc.parseError.reason);
document.write(" Error Line: ");
document.write(xmlDoc.parseError.line);

Turn Validation Off

Validation can be turned off by setting the XML parser's validateOnParse="false".

Example

var xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async="false";
xmlDoc.validateOnParse="false";
xmlDoc.load("note_dtd_error.xml");

document.write(" Error Code: ");
document.write(xmlDoc.parseError.errorCode);
document.write(" Error Reason: ");
document.write(xmlDoc.parseError.reason);
document.write(" Error Line: ");
document.write(xmlDoc.parseError.line);

An Internal Entity Declaration

Syntax

<!ENTITY entity-name "entity-value">

Example

DTD Example:

<!ENTITY writer "Donald Duck.">
<!ENTITY copyright "Copyright W3Schools.">

XML example:

<author>&writer;&copyright;</author>

HINT: An entity has three parts: an ampersand (&), an entity name, and a semicolon (;).

An External Entity Declaration

Syntax

<!ENTITY entity-name SYSTEM "URI/URL">

Example

DTD Example:

<!ENTITY writer SYSTEM "http://www.yahoo.com/entities.dtd">
<!ENTITY copyright SYSTEM "http://www.yahoo.com/entities.dtd">

XML example:

<author>&writer;&copyright;</author>

Use of Elements vs. Attributes

Data can be stored in child elements or in 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 a child element. Both examples provide the same information.

There are no rules about when to use attributes, and when to use child elements. My experience is that attributes are handy in HTML, but in XML you should try to avoid them. Use child elements if the information feels like data.

Way

I like to store data in child elements.

The following three XML documents contain exactly the same information:

A date attribute is used in the first example:

<note date="12/11/2002">
<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>12/11/2002</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>12</day>
 <month>11</month>
 <year>2002</year>
</date>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

Avoid using attributes?

Should you avoid using attributes?

Some of the problems with attributes are:

attributes cannot contain multiple values (child elements can)
attributes are not easily expandable (for future changes)
attributes cannot describe structures (child elements can)
attributes are more difficult to manipulate by program code
attribute values are not easy to test against a DTD

If you use attributes as containers for data, you end up with documents that are difficult to read and maintain. Try to use elements to describe data. Use attributes only to provide information that is not relevant to the data.

Don't end up like this (this is not how XML should be used):

An Exception to my Attribute Rule

Rules always have exceptions.

My rule about attributes has one exception:

Sometimes I assign ID references to elements. These ID references can be used to access XML elements in much the same way as the NAME or ID attributes in HTML. This example demonstrates this:

<messages>
<note id="p501">
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>

<note id="p502">
<to>Jani</to>
<from>Tove</from>
<heading>Re: Reminder</heading>
<body>I will not!</body>
</note>
</messages>

The ID in these examples is just a counter, or a unique identifier, to identify the different notes in the XML file, and not a part of the note data.

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

Declaring Attributes

An attribute declaration has the following syntax:

<!ATTLIST element-name attribute-name attribute-type default-value>

DTD example:

<!ATTLIST payment type CDATA "check">

XML example:

<payment type="check" />

The attribute-type can be one of the following:

Type	Description
CDATA	The value is character data
(en1\|en2\|..)	The value must be one from an enumerated list
ID	The value is a unique id
IDREF	The value is the id of another element
IDREFS	The value is a list of other ids
NMTOKEN	The value is a valid XML name
NMTOKENS	The value is a list of valid XML names
ENTITY	The value is an entity
ENTITIES	The value is a list of entities
NOTATION	The value is a name of a notation
xml:	The value is a predefined xml value

The default-value can be one of the following:

Value	Explanation
value	The default value of the attribute
#REQUIRED	The attribute is required
#IMPLIED	The attribute is not required
#FIXED value	The attribute value is fixed