6/30/2005 04:10:00 pm|W|P|CHERUB|W|P|Creating Types in XML Schemas Restricting Simple Types by Using XML Schema Facets You can restrict the values that are acceptable when defining a simple type. You must base your own simple types on the simple types that are built into XML schemas. You can restrict the possible values of a simple types by using the <xsd:restriction> element. e.g.
<xsd:simpleType name="loanNumberType"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{2} \d{4} \d{2}"/> </xsd:restriction> </xsd:simpleType>
You're using the <xsd:restriction> element's base attribute to indicate that you are basing this type on the xsd:string type. Then you're using an XML schema facet to restrict the actual text that can be stored in attributes of the type you're creating. In this example, the text in the loanNumberType type must much the regular expression pattern "\d{2} \d{4} \d{2}", which matches text strings made up of two digits, a space, four digits, another space, and two more digits (e.g. "22 6666 99"). Regular expressions used with the XML schema pattern facet are the same as those used in the Perl programming languarage. As of this writing, the complete documentation for Perl regular expressions is here. The Visual Studio .NET programming languages, such as Visual Basic.NET and visual C#.NET do support regular expression, and so they support the pattern facet. The following are the available facets and how they constrain data values: totalDigits -- Specifies the maximum number of digits fractionDigits -- Specifies the maximum number of decimal digits pattern -- Specifies a regular expression that text must match whiteSpace -- Can be se to preserve (to preserve white space), replace(to replace all white space with &#20;) or collapse (to collapse multiple contiguous whitespace to one &#20;) enumeration -- Constrains possible values to a specified set maxInclusive -- Specifies the maximum possible value, inclusive maxExclusive -- Specifies the maximum possible value, exclusive minInclusive -- Specifies the minimum possible value, inclusive minExclusive -- Specifies the minimum possible value, exclusive length -- Specifies the data's length, such as number of characters minLength -- Specifies the minimum possible length maxLength -- Specifies the maximum possible length Which facets apply to which predefined simple types? There are tables listing what facets you can use with the various simple data types and the addtional facets of the numeric simple types and simples types that can be ordered. One of the interesting facets is enumeration, which lets you specify a set of values that a data item can select from. Creating XML Schema Choices XML schema choices let you specify a number of items, only one of which will be chosen. To declare a choice in XML schema, you use the <xsd:choice> element. e.g.
<xsd:choice> <xsd:element name = "residentialProperty" type="xsd:string"/> <xsd:element name = "commercialProperty" type = "xsd:string"/> </xsd:choice>
This child element can be either a <residentialProperty> element or a <commercialProperty> element. Using Anonymous Type Definitions When you've created your own types, you've declared elements to be of a certain type and then declared that type. To make use of a type, you give the new type a name and then use that name when decaring an element. However, there's another way as well: you can use anonymous types. An anonymous type is useful if you want to use a type only once and don't want to create many different elements with the same type. So far, the types you've created ouselves have all had names, but if you want to use a type in only on location, it turns out that you can declare it at that location and you don't need to give it a name. This is called an anonymous type. To create an anonymous type definition, you simply enclose an <xsd:simpleType> or <xsd:complexType> element inside an <xsd:element> element declaration. You can also declare attributes in anonymous types. Declaring Empty Elements You just declare empty elements by using a complex type that has no child elements. In other words, you indicate that these are elements that do not contain any other elements, which means they are empty. Empty elements can have attributes; if you declare them using complex types, you can give them attributes. Declaring Mixed-Content Elements XML schemas support true mixed-content elements, in which you can mix text and elements. In other words, character data can appear at the same level as child elements. e.g.
<invoice> To <name> James Blandings </name>: Your monthly payment of ... on <property> The Hackeet Place </property> is due in the three weeks. Thanks. </invoice>
As you can see, both text and elements are mixed inside the <invoice> element in this example. To indicate that this element can handle mixed content, you set the <complexType> elment's mixed attribute to "true". Then all you have to do now is add the declarations for the for the elements that you can use inside the <invoice> element. Whereas DTDs provide only partial support for mixed-content models, schemas provide a more complete syntax that allows you to specify the order and number of child elements in mixed-content elements. However, it is important to note that although you can declare mixed-content elements, you should avoid doing so if possible. Ideally in XML documents, all data is enclosed inside elements. Groupint Elements Together A elements group collects elements together, and you can refer to a group by name. e.g.
<xsd:group ref="aElementGroup" />
To create the group named aElementGroup, you can use the <xsd:group> element. By using groups, you can collect elements together and refer to them by name, which means you can use those groups throughout the XML schema as needed. Grouping Attributes Together Besides grouping elements together, you can also group attributes together. You create attribute groups by using the <xsd:attributeGroup> element. You can use an attribute group named aAttributeGropu, and you can refer to that group as follows in the declaration of the an element:
&xsd:attributeGroup ref="aAttributeGroup" />
The inspiration behind element and attribute groups is parameter entities in DTDs. Parameter netities let you collect declarations together and use them by referring to them simply by using a parameter entity reference. Declaring all Groups In an all group, elements may appear in any order, but there's a catch: all the elements in this kind of group may appear only once or not at all (which means that the allowed values of minOccurs and maxOccurs are 0 and 1 only). This kind of group must be used at the top level of the content model, and the group's children must be individual element -- in other words, this group must itself contain no groups. Handling Namespaces in Schemas DTD's weren't built specially to handle namespace; as you've seen, they really treat namesapce prefixes as part of an element name. XML schemas, on the other hand, were supposed to improve on that situation, and to meet that goal, they support a new attribute: targetNamespace. The targetNamepace attribute can hold the namespaces the XML schema is targeted toward -- i.e. the namspace that the elements in the XML document uses. In other workds, a target namespace lets an XML validator know what XML schema to use to check XML elements in that namespace. It's important that you know that XML schemas treat global element declarations differently thant local element declarations when it comes to working with namespaces; this is because global elements can be used as document elements, whereas local elements can't. As you've seen, globally declared elements and attributes are declared at the top level in the XML schema, directly under the <schema> element. All the other elements and attributes delcared in an XML schema are locally declared. When you start working with namespaces, XML schemas allow you to specify whether locals need to be qualified (that is, whether they need a namespace prefix) when used in an XML document. Declaring Locals Without Qualifying Them To specify whether elements need to be qualified, you use the elementFormDefault attribute of the <schema> element, and to specify whether attributes need to be qualified, you use the attributeFormDefault attribute of the same element. You can set the elementFormDefault and atributeFormDefault attributes to "qualified" or "unqualified". e.g.
<schema xlmns = "http://www.w3.org/2001/XMLSchema" targetNamespace="http://xmlpowercorp" elementFormDefault="unqualified" attributeFormDefault="unqualified">
Because you're dealing with namespaces now, let's take a look at a shorcut way of handling the XML schema URI "http://www.w3.org/2001/XMLSchema" in an XML schema. Up to this point, you've been associating the prefix xsd with that namespace in the XML schema, e.g.
<xsd:schema xmlns:xsd=//www.w3.org/2001/XMLSchema">
However, if you make "http://www.w3.org/2001/XMLSchema" the default namespace in an XML schema, you don't need to use a prefix for the XML schema elements. Though it can save some time, but you have to be a little careful because now the XML validator will assume that everying in the "http://www.w3.org/2001/XMLSchema" namespace. That's a problem because when you say, e.g. that the <document> element is of the documentType type, the XML validator needs to know where to find the documentType type; it won't find that type defined in the default "http://www.w3.org/2001/XMLSchema" namespace. You can indicate that local types are declared locally by using a new namspace prefix, such as xmp (short for XML Power Corp) . If only two elements that are global in the XML schema, which are <document"> and <comment>, so they're the only ones that need to be qualified with a namespace prefix. Declaring and Qaulifying Locals We can require that locals be qualified with a namespace prefix. e.g., we can assign the value "qualified" to the elementFormDefault attribute instead of using "unqualified". Now you have to qualify both locals and globals in the XML documents. You can also require that attributes be qualified by setting attributeFormDefault to "qualified". Now all elements and attributes, both local and global, will have to be qualified. Rather than prefix every element and attribute with xmp:, however, you can make things easier by just putting the entire XML document into the "http://xmlpowercorp" namespace. Up to this point, you've specified that all locals must be either qualified or unqualifed, but there's also a way of working on locals individually, by using the form attribute. e.g. you can leave all locals unqualified expect for a single attribute, phone, which must be qualified:
<xsd:attribute name="phone" type="xsd:string" use="optional" form="qualified"/>
Annotating an XML Schema As with DTDs and XML documents, you can add documents to XML schemas. You can use the XML comments in XML schema. XML schemas also define three new element that you use to add annotation to schemas: <xsd:annotation>, <xsd:documentation>, <xsd:appInfo>. The <xsd:annotation> element is a container for the other two. The <xsd:documentation> element holds text intended for human readers, but it's a little more than standard XML comments because the text in <xsd:documentation> elements can be stripped out by an XML processor and used to document an XML schema. The <xsd:appInfo> element can be used to pass along instructions to the XML pocessor that is reading the XML schema. You can use these elements anywhere you like in an XML schema.|W|P|112015008309486991|W|P|Teach Yourself XML in 21 days, Day 7|W|P|10/02/2005 05:24:00 pm|W|P|Blogger Steve Austin|W|P|Interesting blog. I have a xforms blog.6/26/2005 04:44:00 pm|W|P|CHERUB|W|P|Creating Valid XML Documents: XML Schemas A more comprehensive and detailed way of specifying the syntax of XML documents, followed the W3C's response, is XML schemas. A good resource on XML schemas is the W3C XML Schema Activity Page. Using XML Schema Tools More and more software tools are appearing that can generate XML schemas. Such as: HiT Software -- This is an online automatic XML schema generator and DTD to XML schema converter. You just let it upload a document, and it creates an XML schema for free. Validating XML Documents by Using XML Schemas XSV -- This is the online W3C XML schema validator XML Schema Definition Language -- XSD schema. How do you connect an XML schema, such as ch0603.xsd, to an XML document? Different XML processors do it in different ways, but a standard is emerging. If you define a namespace, usually named xsi, for the URI www.w3.org/2001/XMLSchema-instance, you can then use an attribute named xsi:schemaLocation in the document element to specify the URI of the document's XML schema. e.g.
<? xml version = "1.0" > <document xmlns = "http://xmlpowercorp" xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://xmlpowercorp ch0603.xsd" > ... </document>
It turns out that it's actually not necessary to embed an xsi:schemaLocation attribute in an XML document to validate it by using Internet Exploer -- you can use JavaScript to tell Internet Explorer where to find the XML schema. Creating XML Schemas The first thing to note about the XML schema is that it's a well-formed XML document. It uses proper XML elemnts to declare the syntax of the XML document. e.g.
<?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:annotation> <xsd:documentation> Test XML schema. </xsd:documentation> </xsd:annotation> <xsd:element name="document" type="documentType"/> <xsd:complexType name="documentType"> <xsd:sequence> <xsd:element ref="comment" minOccurs="1"/> <xsd:element name="test1" type="recordType"/> <xsd:element name="test2" type="xsd:string"/> </xsd:sequence> <xsd:attribute name="documentDate" type="xsd:date"/> </xsd:complexType> <xsd:element name="comment" type="xsd:string"/> ... </xsd:schema>
To start, XML schema uses an XML declaration to declare the namespace prefix xsd (the usual name for this namespace in XML schemas), and it assigns the URI www.w3.org/2001/XMLSchema to that prefix, which is how the W3C says you must do things in XML schemas, in a special element named <xsd:schema>. In the example, you're putting the <xsd:documentation> element with the text "Text XML Schema" inside the <xsd:annotation> element, creating a comment in the schema. Annotations like this one are ignored by XML processors. You use <xsd:element> to declare elements and <xsd:attribute> to declare attributes. The Built-in XML Schema Elements These are the elements you can use in XML shemas. These elements are usually used with the namespace www.w3.org/2001/XMLSchema and namespace prefix xsd, so, e.g. the <all> element would usually be <xsd:all>, and so on. List -- Legal XML Schema Elements all -- Allows elements in a group to be in any order annotation -- Creates an annotation that lets you add comments to an XML schema any -- Allows any element to appear in a sequence or choice element anyAttribute -- Allows any attribute to appear in the containing complex type or in the containing attribute group appinfo -- Contains information within an annotation element attribute -- Declares an attribute attributegroup -- Creates an attribute group, which allows attribute declarations to be used as a group for complex type definitions. choice -- Allows one, and only one, of the given elements to appear in the containing element complexContent -- Specifies restrictions on a complex type that contains mixed content or elements. complexType -- Declares a complex type documentation -- Contains text that can be placed in an annotation element element -- Declares an element extension -- Extends a simple or complex type that has simple content field -- Contains an XML Path Language (XPath) expression that specifies the value for a constraint group -- Groups element declarations together so that they can be used as a group in complex type definitions import -- Imports a namespace whose schema components can be used by a shema include -- Includes teh given schema document in the current schema key -- Specifies that an attribute value or element value must be a key keyref -- Specifies that an attribute value or element value must match the value of the given key list -- Declares a simple type element as a list of values of a given data type notation -- Holds a notation to describe the format of non-XML data inside an XML document redefine -- Allows simple and complex types and groups to be redefined in the current schema restriction -- Declares constrains, such as restricting the type of data schema -- Contains a schema definition selector -- Gives an XPath expression that can select elements for an identity constraint sequence -- Constrains the given elements to appear in the given sequence in the XML document simpleContent -- Contains extensions or restrictions on a type simpleType -- Declares a simple type for use with the type attribute when you declare element or attributes union -- Declares a simple type as a collection of values of simple data types unique -- Specifies that an attribute or element value must be unique Creating Elements and Types To declare elements, you use the <xsd:element> element in XML schemas. When you declare an element, you can specify its type. e.g. the element named <comment> in the sample XML document you've been working with just contains text, e.g.
<comment> Good Rist </comment>
You can declare the <comment> element by using <xsd:element> and giving it the name "comment" and the type xsd:string, like this:
<xsd:element name="comment" type="xsd:string"/>
You've used the built-in type xsd:string. However, you can also define our own types. In fact, there are two types that you can create -- simple and complex types. Elements that enclose child elements or have attributes are complex types. In other words, complex types can have internal structure, such as child elements and attributes, but simple types cannot. For example, attributes are always simple types because attribute values cannot have any internal structure. Using Simple Types There are some built-in simple types for XML schemas, such as xsd:string, xsd:int, xsd:date, and so on. Note how detailed these types are compared to DTDs; remember that with DTDs, you can't define data types. Declaring out own types lets you restrict the values those types can take. For example, take a look at the <term> element in the XML document. This element gives the term, i.e. the length parameter, and you want that number to be 30 or less, so you can use a <xsd:simpleType> element, enclosing a <xsd:restriction> element, to restrict the possible values that can be used in the <term> element. Inside the <xsd:restriction> element, you can use the <xsd:maxInclusive> element to restrict possible values in the <term> element to 30 years or less, e.g.
<xsd:element name="term"> <xsd:simpleType> <xsd:restriction base="xsd:integer"> <xsd:maxInclusive value="30"/> </xsd:restriction> <simpleType>
Using Complex Type You create new complex types by using the <xsd:complexType> element in schemas. For example, the <document> element can contain other elements, so you need to decare it by using a complex type, which you can call documentType in our XML schema. In the XML schema, you can declare the <document> element to be of the documentType type:
<xsd:element name="document" type="documentType"/>
You create the documentType type by using an <xsd:complexType> element. In this case, you want to indicate that the subelements in <document> will be <comment>, < test1> and <test2>, in that order, so you use the <xsd:sequence> element, such as:
<xsd:element name="document" type="documentType"/> <xsd:complexType name="documentType"> <xsd:sequence> <xsd:element ref="comment" minOccurs="1"/> <xsd:element name="test1" type="recordType"/> <xsd:element name="test2" type="xsd:string"/> </xsd:sequence> <xsd:attribute name="documentDate" type="xsd:date"/> </xsd:complexType>
You create a type in an XML schema and then you can declare elements for that type. If you want to use a complex type, you have to create it, and you do that by using the &xsd:complexType> elememt. One way of declaring elements, as you've seen today, is to specify the element's name and type, as in in following example, which declare the <comment> element;
<xsd:element name="comment" type="xsd:string"/>
Using the ref attribute lets you make use of an element that has already been declared. Note, however, that you can't just included any element by reference -- the element you refer to must have been declared globally, which means that it is itself not part of any other complex type. The other option is to declare elements inside other declarations, which is declaring them locally. A global element or attribute declaration appears as an immediate child element of the <xsd:schema> element, and when you declare an element or attribute globally, it can be used in any complex type. Using the ref attribute in this way is a powerful technique. Specifying a Number of Elements The <document> element is declared to be of the documentType type, and in that type, you use the minOccurs attribute to indicate that the <comment> element must occur at least once:
<xsd:element ref="comment" minOccurs="1"/>
You can specify the minimum number of times an element appears by using the minOccurs attribute and the maximum number of times it can appear by using the maxOccurs attribute. Keep in mind that you can use minOccurs and maxOccurs only with local declarations, not global ones. The default value for minOccurs is 1, and the default for maxOccurs is the value of minOccurs. To specify that there is no upper bound to the maxOccurs attribute, you set it to the value "unbounded". Specifying Element Default Values The <xsd:element> element has two attributes, fixed and default, that let you specify an element's default value. The fixed attribute sets the value of an element; for example, setting the <term> element's fixed attribute to an integer value of 800 means that the element will always have that vale:
<xsd:element name="term" type="xsd:integer" fixed="800"/>
The default attribute lets you set the default value of an element -- that is, the value that the element has if you don't specify any other value. For example, here's how you can specify a value of 800 as a default value instead of fixing this element's value at 800:
<xsd:element name="term" type="xsd:integer" default="800"/>
Creating Attributes To declaring an attribute, you use the <xsd:attribute> element as in the examples, which declares an attribute named phone for the recordType type.
<xsd:attribute name="phone" type="xsd:string"/>
<xsd:attribute> has a type attribute, and its attributes must always be of a simple type. You can also indicate whether an attribute is required or optional, or whether it has a default value. To do that, you use the <xsd:attribute> element's use and value attribute. e.g.
<xsd:element name="term" type="xsd:integer" default="800" use="optional"/>
Here are the vaules you can give to the use attribute: default -- If you don't use the use attribute, its value is the default vale set with the value attribute. If you do use it, its value is the value you assign it. fixed -- This value makes the attribute fixed. You can set its value by using the value attribute. optional -- This value makes the attribute optional, which means the attribute may have any value. prohibited -- This value means the attribute cannot be used. required -- This value makes the attribute required. The attribute can have any value. The value attribute contains a value if you need to specify one. For example, the following attribute declaration creates an attribute named year with the integer fixed value "2005":
<xsd:attribute name="year" type="xsd:int" use="fixed" value="2005">
Here's another example of an attribute declaration. This example gives the integer attribute year with the default value "2005":
<xsd:attribute name="year" type="xsd:int" use="default" value="2005">
|W|P|111980141276868393|W|P|Teach Yourself XML in 21 days, Day 6|W|P|10/02/2005 05:24:00 pm|W|P|Blogger Steve Austin|W|P|Interesting blog. I have a xml tutorial blog.6/24/2005 04:38:00 pm|W|P|CHERUB|W|P|Handling Attributes and Entities in DTDs Both attributes and entities are essential parts of XML, this chapter is going to explain how to support them in valid XML documents. Declaring Attributes in DTDs As in HTML, an attribute is a name-value pair that you can use in a start tag or an empty tag to provide additional information for an element. You can declare a list of attributes for an element by using the <!ATTLIST> element in the DTD. e.g.
<! ATTLIST element_name attribute_name type default_value >
Here, element_name is the name of the element for which you're declaring attributes, attribute_name is the name of an attribute you want to declare, type is the attribute's type, the default_value sepcifies the default value of the attribute. A real example is:
<! ATTLIST employee supervisor CDATA #IMPLIED supervisor CDATA #IMPLIED division CDATA #IMPLIED fulltime CDATA #IMPLIED >
the use of the above declared attribute can be:
<employee supervisor = "no" division = "plastics" fulltime = "yes">
All you have to do is use an <!ATTLIST> element to declare the attributes for an element. It's a little more involved to use this element than to use <!ELEMENT>, however, because you're restricted to certain types and default values for attributes in DTDs. Using the Legal Default Values and Attributes Types When you're declaring attributes in DTDs, these are the possible default_value settings you can use in <!ATTLIST> elements; value -- Specifies a text value and must be enclosed in quotes #IMPLED -- Makes an attribute optional #FIXED value -- Sets the attribute's value to value #REQUIRED -- Means that this attribute is required and must be given a value These are the possible type values you can use CDATA -- Specifies character data, which is just text without markup ENTITY -- Specifies an entity name ENTITIES -- Specifies multiple entity names, which are seperated by whitespace Enumerated -- Specifies one value from a list of values (an enumeration) ID -- Specifies an ID attribute, which holds a proper XML name IDREF -- Holds the ID value of some other element IDREFS -- Holds multiple ID values of elements, seperated by whitespace NMTOKEN -- Specifies text made up of XML name characters, or tokens. NMTOKENS -- Specifies multiple NMTOKEN items, seperated by whitespace NOTATION -- Specifies a notation name that holds a format description (such as a MIME type) Specifying Default Values Immediate Values You can specify a default value for an attribute simply by listing that value, in quotes, in the attribute's declaration in the <!ATTLIST> element, making it an immediate value. If you give an attribute a default value and then don't use that attribute in an element, the attribute is automatically given the default value. e.g.
<! ATTLIST employee supervisor CDATA "no" >
The #REQUIRED You can specify a default value of #REQUIRED to indicate that an attribute is required. e.g.
<! ATTLIST employee supervisor CDATA #REQUIRED >
The #IMPLIED Attributes declared with #IMPLIED are optional. For example, you can use the #IMPLIED default value if you want to all the document author to include an attribute, but you don't want to require it. e.g.
<! ATTLIST employee supervisor CDATA #IMPLIED >
All the following examples are valid:
<employee supervisor = "no"> <employee>
The #FIXED The final default value is #FIXED, which you use when you want to assign a fixed value to an attribute -- a value that the attribute will always have. e.g.
<! ATTLIST employee supervisor CDATA #FIXED "en" >
Specifying Attribute Types The CDATA As you've already seen, the CDATA data type stands for character data. Unlike parsed character data (PCDATA), which is assumed to have already been parsed, the character data in attribute values is read and parsed by the XML processor. Enumerated Types An attribute enumeration is just a list of possible values that an attribute can take. e.g.
<! ATTLIST employee supervisor (yes | no) "no" >
The NMTOKEN Attribute Type The attribute type NMTOKEN stands for name token, and it lets you assign to an attribute any value made up of legal XML name characters. Note that NMTOKEN characters can not include whitespace. e.g.
<! ATTLIST employee state NMTOKEN #REQUIRED >
This attribute can be used as:
<employee state = "NY">
The NMTOKENS Attribute Type You can use the NMTOKENS attribute type when you want to list multiple values made up of NMTOKEN values, seperated by whitespace, so, it could include whitespace now. e.g.
<! ATTLIST employee state NMTOKENS #REQUIRED >
This attribute can be used as:
<employee state = "New York">
The ID Attribute Type An important attribute type is the ID type. There's a special meaning to an element's ID value because sometimes XML processors use an ID attribute to identity an element. Therefore, XML processors are supposed to make sure that no two elements have the same value for the attribute that is of the type ID in a document; in addtion, you can give an element only on attribute of this type. e.g.
<! ATTLIST employee id ID #REQUIRED >
This attribute can be used as:
<employee id = "A1112">
The IDREF Attribute Type We can also use IDREF (which stands for ID reference) attributes to tie an element to another element, using the other element's ID value as a reference. The following example gives each employee an id attribute and also creates an optional supervisor attribute of type IDREF, which will store the ID value of an employee's supervisor:
<! ATTLIST employee id ID #REQUIRED supervisor IDREF #IMPLIED >
this attribute can be used as:
<employee id = "A1112"> <employee id = "A1113" supervisor = "A1112">
The ENTITY Attribute Type The ENTITY type lets you assign to an attribute the name of an entity you've declared. The following example gives the entity name PHOTO1221 to the image file 1221.gif and the entity name PHOTO1222 to the image file 1222.gif:
<! ENTITY PHOTO1221 SYSTEM "1221.gif" > <! ENTITY PHOTO1222 SYSTEM "1222.gif" >
If 1221.gif and 1222.gif held the photos of various employees, you could indicate that this is the case by using an ENTITY attribute named photo, like this:
<! ATTLIST employee photo ENTITY #IMPLIED >
this attribute can be used as:
<employee photo = "PHOTO1221">
Using ENTITY attribute is a good way of working with entities. The ENTITIES attribute Type Attributes of this type can hold lists of entity names, separated by whitespace. The NOTATION Attribute Type You can assign to NOTATION attribute values that you've declared to be notations. Notations specify the format of non-XML data, and they're typically used to describe the storate format of external entities such as image fiels. e.g. one popular type of notations is Multipurpose Internet Mail Extension (MIME) type, such as application/xml, text/html, image/jpeg, and so forth, which are often used to specify data storage formats. There is a list of all the avaliable MIME types. When you want to declare a notation, you use the <!NOTATION> element in a DTD like this:
<! NOTATION name SYSTEM "external_id" >
You can also use the PUBLIC keyword for public natation if you supply a fomal public identifier (FPI), like this:
<! NOTATION name PUBLIC FPI "external_id" >
An example is:
<! NOTATION jpg SYSTEM "image/jpeg" > <! NOTATION gif SYSTEM "image/gif" > <! ATTLIST employee imagetype NOTATION (jpg | gif) #IMPLIED >
This attribute can be used as:
<employee imagetype = "gif">
Handling Entities An entity in XML is simply a data item. Entities can also be internal or external. An internal entity is defined completely inside the XML document that uses it. An external, on the other hand, is stored externally, such as in a file; to refer to an external entity in XML, you can use a URI. You declare an entity in a DTD, and then you can refer to it with an entity ference in the rest of the XML document. Creating Internal General Entity References You use the <!ENTITY> element to declare an entity. e.g.
<! ENTITY name definition >
In this case, the name of the entity is just the name you want to use to refer to the entity, but an entity's definition can take several different forms. The simplest way of defining an entity is just to use the text that you want XML processors to replace entiry references with. e.g.
<! ENTITY copyright "(c) XML Power Corp. 2005" >
You can use the entity copyright in the XML document like this:
<copy> &copyright; </copy>
The replacement text for internal general entity references doesn't have to be quoted text; you can use UTF-8 character codes directly. You also can nest entity references. e.g.
<! ENTITY me "Cherub" > <! ENTITY copyright "(c) &me; 2005" >
Note that although you can nest entity references, they can't be circular, or the XML processor will go nuts. e.g.
<! ENTITY me "&copyright; Cherub" > <! ENTITY copyright "(c) &me; 2005" >
Circular entity references like the above are illegal in valid documents. General entity references, such as &copyright;, are valid only in the body of the XML document, not in the DTD itself. e.g. this is not legal:
<! ENTITY employeeContent "(copy, name, hiredate, projects)" > <! ELEMENT employee &employeeContent; >
The way you should handle a situation like this ,where an entity reference is used in the DTD itself, is by using parameter entities. Creating External General Entity References You can use the SYSTEM keyword or the PUBLIC keyword when declaring external general entities. The syntax is:
<! ENTITY name SYSTEM URI > <! ENTITY name PUBLIC FPI URI >
By using external general entities, you can assemble XML documents together from various pieces stored in their own files. That can be very useful if, for example, you have standard headers or footers or copyright notices that you want to use. Associating Non-XML Data with an XML Document To declare an external unparsed entity, you use an <!ENTITY> element with either the SYSTEM keyword or the PUBLIC keyword, like this (note the keyword NDATA, which indicates that you're referring to an unparsed entity):
<! ENTITY name SYSTEM value NDATA type > <! ENTITY name PUBLIC FPI value NDATA type >
name is the name of the external unparsed entity, value is the value of the entity, such as the name of an external file, and type is a declared notation. For example, to explicitly indicate that 1221.gif is an external entity that should not be parsed, you can create a notation name gif for GIF files;
<! NOTION gif SYSTEM "image/gif" >
Next, you can declare 1221.gif as an unpased entity that uses the gif notation;
<! ENTITY PHOTO1221 SYSTEM "1221.gif" NDATA gif >
You can create an ENTITY attribute named photo for the <employee> element;
<! ATTLIST employee photo ENTITY #IMPLIED >
Finally, you can assign the photo attribute the value PHOTO1221;
<employee photo = "PHOTO1221">
Note that in this example, you do NOT use an entity reference (that is, &PHOTO1221;) because you do NOT want the XML processor to parse 1221.gif. Creating Internal Parameter Entities It turns out that it can be useful to use parameters in DTDs, and you use parameter entities and parameter entity references (which can only be used in DTDs) for that. In fact, there's one more restriction on DTDs: Parameter entity references that you use insied an already existing DTD declaration can appear only in the DTD's external subset, which means that the part of the DTD that is external. You can declare a parameter entity by using the <!ENTITY> element, but you include a % to show that you're declaring a parameter reference. e.g.
The following is an example that shows how to use an internal parameter entity:
<! ENTITY % project "<! ELEMENT project (product, id, price) >" >
When you use the parameter entity reference %project; in the DTD, it will be replaced with the text <! ELEMENT project (product, id, price) >. Using INCLUDE and IGNORE to Parameterize DTDs There are two important directives that you need to know abut when it comes to working with DTDs: INCLUDE and IGNORE. Directives are special commands to the XML processor, and INCLUDE and IGNORE are specially designed to customize a DTD by including or omitting sections of that DTD. The following is the syntax:
<![ INCLUDE [DTD Section]] > <![ IGNORE [DTD Section]]>
The reason you see INCLUDE and INGORE in DTDs is that by using these directives, you can create parameterized DTDs.
|W|P|111963048067318369|W|P|Teach Yourself XML in 21 days, Day 5|W|P|6/23/2005 02:14:00 pm|W|P|CHERUB|W|P|Creating Valid XML Documents: DTDs We define the syntax of an XML document by using a DTD, and we declare that definition in a document by using a document type declaration. We can use a <! DOCTYPE > element to create a DTD, and the DTD appears in that element. The following forms are valid:
<! DOCTYPE rootname [DTD] > <! DOCTYPE rootname SYSTEM URI > <! DOCTYPE rootname SYSTEM URI [DTD] > <! DOCTYPE rootname PUBLIC identifier URI > <! DOCTYPE rootname PUBLIC identifier URI [DTD] >
The first step in creating that DTD is to declare the elements that appear in the XML document. To declare the syntax of an element in a DTD, we use the <! ELEMENT > element like this:
<! ELEMENT name content_model >
In this syntax, name is the name of the element we're declaring and content_model is the content model of the element. A content model indicates what content the element is allowed to have, for example, you can allow child elements or text data, or you can make the element empty by using the EMPTY keyword, or you can allow any content by using the ANY keyword.e.g.
<! ELEMENT document (employee)* >
Handling ANY content If you give an element the content model ANY, that element can contain any content, which means any elements and/or any character data. What this really means is that you're turning off validation for this element because the contents of elements with the content model ANY are not even checked. Specifying Child Elements You can specify what child elements an element can contain in that element's content model. The above example specifies that a <document> element can contain <employee> element. The * here means that a <document> element can contain any number, including zero, <employee> elements. You can list multiple elements in a content model, which is called creating a sequence. You use commas to separate the elements you want to have apear, and then the elements have to appear in that sequence in our XML document. For example, if you declare this sequence in the DTD:
<! ELEMENT employee (name, hiredate, projects) >
the <employee> elements can contain <name>, <hiredata>, and <projects> elements, and in that order. Handling Text Content In a DTD, we refer to parsed character data as #PCDATA. Note that this is the only way to refer to text data in a DTD -- you can't say anything about the actual format of the text, although that might be important if you're dealing with numbers. In fact, this lack of precision is one of the reasons that XML schemas were introduced. Specifying Multiple Child Elements There are a number of ways of specifying multiple children by using symbols:
x+ -- Means x can appear one or more times; x* -- Means x can appear zero or more times; x? -- Means x can appear once or not at all; x, y -- Means x followed by y; x | y -- Means x or y, but not both.
You can use the +, *, and ? symbols in content model sequences. e.g.
<! ELEMENT employee (name+, hiredate?, projects*) >
If fact, you can get even more powerful results by using the +, *, and ? operators inside sequences. By using parenttheses, we can create subsequences -- that is, sequences inside sequences. e.g.
<! ELEMENT employee ((name, age?, phone*)+, hiredate, projects) >
Allowing Choices By using (x | y | z), DTDS can support choices of containg either <x>, <y> or <z>. Allowing Mixed Content When using a DTD, you can allow an element to contain text OR child elements, giving it a mixed content model. Note that even with a mixed content model, and element can't contain child elements AND text data at the same level at the same time. However, you can set up a DTD so that an element can contain EITHER child elements OR text data. e.g.
<! ELEMENT product (#PCDATA | stocknumber)* >
Allowing Empty Elements Elements don't need to have any content at all, of course; they can be empty. As you would expect, you can support empty element by using DTDs. In particular, you can create an empty content model with the keyword EMPTY. e.g.
<! ELEMENT intern EMPTY >
Commenting a DTD Commenting a DTD accord to the same syntax with the XML. Supporting External DTDs We can also store DTDs externally, in entirely separate files, which usually use the extension .dtd. That way, if you want to make changes in the XML application, you only need to change the DTD once, not in dozens of separate files. There are two ways to suport external DTDs -- as private DTDs for personal or limited use and as public DTDs for public use. Creating Private DTDs You specify that we're using an external private DTD by using the SYSTEM keyword in the element, e.g.
<! DOCTYPE document SYTEM "ch04_07.dtd" >
This example specifies the name of the <document> element, the SYSTEM keyword to indicate that the example is using a private external DTD, and the name of the external DTD file. We must change the standalone attribute from "yes" to "no". e.g.
<? xml version = "1.0" encoding = "UTF-8" standalone = "no" ?>
Note that the external DTD simply holds the part of the document that was originally between the [ and ] in the inner version of element. If you want to use an onlin XML validator, you need to supply a URL like the following for an external DTD:
<! DOCTYPE document SYSTEM "http://sample.com/sample.dtd" >
Creating Public DTDs Creating and using a public external DTD can take a little more work. In this case, you use the PUBLIC keyword instead of SYSTEM in the <!DOCTYPE> DTD. To use the PUBLIC keyword, you must also create a formal public identifier (FPI), which is a quoted string of text, made up of four fields separated by //. e.g. the official FPI for transitional XHTML 1.0 is -//W3C//DTD XHTML 1.0 Transitional//EN. Here are the rules for creating the fields in FPIs:
1. The first field indicates whether the DTD is for a formal standard. For DTDs you create on your own, this field should be -. If a non-official standard body has created the DTD, you use +. For formal standard bodies, this field is a reference to the standard itself (such as ISO/IEC 19775:2003) 2. The second field holds the name of the group or person responsible for the DTD. You should use a name that is UNIQUE. 3. The third field specifies the type of the document the DTD is for and should be followed by a unique version number of some kind. 4. The fourth field specifies the language in which the DTD is written.
When you use a public external DTD, we can use the element like this:
<! DOCTYPE rootname PUBLIC FPI URI >
Using Internal and External DTDs at the Same Time You can also use BOTH internal and external DTDs if you use these forms of the <!DOCTYPE> element:
<! DOCTYPE rootname SYSTEM URI [DTD] > <! DOCTYPE rootname PUBLIC identifier URI [DTD] >
In these cases, the external DTD is specified by URL and the internal on by DTD. Combining internal and external DTDs like this is a good idea if you have a standard DTD that we share with other XML documents but also want to do some customizatoin in certain XML documents. Handling Namespaces in DTDs Another important topic when it comes to working with DTDs is how to handle namespaces. As we already know, a namespace name is really just a name prepended to an element or attribute name with a colon. That means that as far as a DTD is concerned, those new names have to be declared. The syntax is to add the following declaration in DTDs when using a namespace, (like declare an attribute of a element, which is concerned in Day 5).
<! ATTLIST emp:document xmlns:emp CDATA #FIXED "http://www.xmlpowercorp.com/dtds/" >
|W|P|111953586424463735|W|P|Teach Yourself XML in 21 days, Day 4|W|P|6/14/2005 10:03:00 pm|W|P|CHERUB|W|P|Creating Well-Formed XML Documents A XML document is well-formed if:
1. Taken as a whole, it matches the production labeled document; 2. It mees all the well-formedness constraints given in XML 1.0 specification; 3. Each of the parsed entities, which is referenced directly or indirectly within the document, is well-formed.
Matching the Production Labeled document A XML document, to be well-formed, must follow the document production, which means that the document itself must have three parts:
a prolog a root element a miscellaneous part
siblings, child, parent relationships A parent element can enclose an indefinite number of child elements Well-Formedness Constraints 1. W3C says you should always include the XML declaration first thing; 2. Using only legal character references; 3. A XML document must include one or more elements. The first element is the root element; 4. Every non-empty element in XML must have both a start tag and an end tag; 5. Empty elements which have no content, though they can have attributes, are made up entirely of one tag, and must always end with /<; 6. The root element must contain all the other elements in the document; (It is convenient for a XML processor to navigate the entire document) 7. Nesting elements requires that if an element contains a start tag for a non-empty tag, it must also contain that element's end tag; 8. You can not use the same attribute more than once in one start tag or empty element tag; 9. You must quote every value you assign to an attribute, using either single quotation marks or double quotation marks; 10. You should avoid references to external entities in attribute values. Here the external entities mean XML style references - gengeral entity references or parameter entity references, not just, for example, using an image file's name. It also means that an XML processor doesn't have to replace an attribute value with the contents of an external entity. 11. You are not supposed to use < in attribute values, because an XML processor might mistake it for markup. 12. You should avoid using < and & for anything else than start tag and the start entity reference. For JavaScript, it is maybe a problem... Three optional solutions:
Enclose JavaScript codes in a CDATA section; Reverse the logical sense that using NOT great and equal t0 instead of below; Place the JavaScript codes in an external file and like it when necessary; (Recommended)
XML Namespaces Namespace is derived to handled the problem of tag names conflicting. Namespaces give you a way to make sure that one set of tags will no conflict with another. You prefix a name to tag and attribute names. To define a new namespace, use the xmlns:prefix attribute, where prefix is the prefix you want to use for the namespace. e.g.
<employee xmlns:hr="http://www.example.com/example">
URI, Uniform Resource Identifiers To define a namespace, you assign the xmlns:prefix attribute to a unique identifier, which in XML is usually a URI that might direct the XML processor to a DTD for the namespace. URI, Uniform Resource Identifiers, is expanded from the idea of standard URL, Uniform Resource Locators. In theory, a URI can point not just to a single resource, but to a cluster of resources, or to arcs of resources along a path. But the truth is that the whole idea of URI as the next step after URL is still being developed. After defining the hr namespace in the above example, you can preface every tag and attribute name in this namespace with hr: like this:
<hr:employee>
Using namespaces keeps elements separate by actually changing tag and attribute names. Two namespace names are reserved: xml and xmlns. You can use the xmlns:prefix attribute to define a namespace, or you can use the xmlns attribute by itself to define a default namespace. When you define a default namespace, elements and attributes without a namespace prefix are in that default namespace. e.g.
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:m="http://www.w3.org/1998/Math/MathXML" >
The above example create a default namespace for XHTML tags and a m namespace for MathXML tags inside element html. Namespaces aren't used solely to avoid tag and attribute name conflicts, using a namespace also indicates to an XML processor what XML application you're using.|W|P|111878572612750746|W|P|Teach Yourself XML in 21 days, Day 3|W|P|11/28/2005 08:33:00 am|W|P|Blogger job opportunitya|W|P|Irresistible blog. I look for blogs like this one
when time allows me to. I enjoyed the site and I'll
check it next time!
Search for my Calling Solutions blog, it will leave you speechless.6/12/2005 11:47:00 am|W|P|CHERUB|W|P|Excuse me a break... Too short of time to do more things...|W|P|111857329934890092|W|P|No time|W|P|6/08/2005 10:53:00 pm|W|P|CHERUB|W|P|Necessary tools necessary to help you develop your XML are editors, browsers, and validators. XML character Encoding: ASCII, Unicode, and UCS W3C chose Unicode, which holds 65,536 characters, as XML's standard Encoding. The first 256 Unicode characters correspond to the ASCII character set. There's another character encoding availabe that has even more space than Unicode - the Universal Character System, UCS, also called ISO 10646, uses 32 bits - two bytes - per character. This give it a range of two billion symbols - and a good thing, too, since there are more Chinese characters alone than there is space in Unicode. UCS also encompasses the smaller Unicode character set - each Unicode character is represented by the same code in UCS, in much the same way that the Unicode encompasses the smaller ASCII character set. XML actually supports a compressed version of Unicode created by the UCS group called UCS Transformation Format - 8, UTF-8. UTF-8 includes all the ASCII codes unchaged, and uses a single byte for the most common Unicode characters. UCS itself has also been compressed in the same way into a character set named UTF-16, which uses two bytes (instead of the normal four that UCS uses) for the most common characters, and more bytes for the less common characters. W3C requires all XML processors to support both UTF-8, and UTF-16, and those are the only two W3C requires. UTF-8 is so widespread that an XML processor will assume you're using it if you omit the encoding attribute. Character reference stands for a Unicode character and begin with &, followed by a numeric code specifying a character, and ends with ;. Understanding XML Markup and XML Data XML documents are combinations of markup and text data. The markup in a document gives it its structure. Markup includes start tags, end tags, empty element tags, entity references, character references, comments, CDATA section delimiters, document type declaractions, and processing instructions. All the text in an XML document that is not markup is data.
Tags begint with < and end with > General entity references start with & and end with ; Parameter entity reference, which start with % and end with ;, are used in DTDs.
Before XML document is parsed, text data is called character data; after it's been parsed and general entity references have been replaced with the entities they refer to, the text data is called parsed character data. Using Whitespace and Ends of Lines Spaces, carriage returns, line feeds, and tabs are all treated as whitespace in XML.
attribute xml:space
Creating Prologs Prologs appear at the beginning of XML documents, and contain information about the rest of a the document. A problog can contain XML declaractions, XML comments, processing instructions, whitespace, and doctype declaractions. W3C says you should include at least an XML declaration in all XML documents. XML DeclaractionXML declaractions tell XML processors what version of XML you're using, what character encoding the document is written in, and so on. All XML documents should start with an XML declaraction, which should be the first line in an XML document.
attibute: version, encoding, standalone (Set to "yes" if the document does not refer to any external documents or entities, "no" otherwise. It is optional)
XML Comments: You start a comment with <!-- and end it with -->. You're only supposed to use comments outside markup. You should not use the character sequence -- in the text of a comment. In particular, the XML 1.0 specification says that comments can not end with the sequence --->. Also, comments can not come before an XML declaraction (nothing can).In most XML processor, you can use comments to exclude sections of a document from being treated as markup. Processing Instructions: Processing instructions are instructions to the XML processor, not general data-handling items like elements. A common processing instruction is <?xml-stylesheet?>, but that's not an official W3C processing instruction built into XML. In other words, processing instructions must be understood by the XML processor, so they're processor-dependent. Creating Tags and Elements. Tags and Elements: Tag names are case sensive. Empty Elements: In XML, you close an empty element with />. Empty elements can have attributes. Root Element: Each well-formed XML document must contain one element that contains all the other elements, and the containing element is called the root element. Attributes: The values you assign to attributes must be quoted, even if they're numbers, and that if you use an attribute, it must be assigned a value. Attribute names must follow the same rules as those for element names. If the attribute value contains ingle or double quotes or both, you can use the XML-defined general entity references for a single quotation mark and for a double quotation mark.
attribute: xml:lang
Attributes, Elements, Data: Attributes hold data, and elements hold data, too. You can't specify document structure using attribute. A good rule to follow, therefore, is to use elements to structure your document, and to use attributes when you have more information to include about a specific element. CDATA Sections: escaping means you want XMl processor to avoid to replace the general entity reference to what it refer to. You can achieve escaping by placing you text data in a CDATA section. CDATA stands for character data, as opposed to parsed character data, which is PCDATA. You use the CDATA section to tell the XML processer to leave the enclosed text alone, and pass it on uncharged. You cannot nest CDATA sections. To avoid confusing an XML processor reading an XHTML page with embedded JavaScript operator, which may use the less than (<), you can enclose that JavaScript in a CDATA section. Entities: There's another type of item you can work with in XML documents - entities, which can be parsed or unparsed. An entity simply means a data item, such as a section of text or binary data. A parsed entity is one that you refer to with an entity reference. Entity references are replaced by XML processor with the entities they refer to. You can define your own general entity refereneces. Unparsed entities can be binary data that you don't want parsed, or even non-XML text, and they're usually external to you XML document. You don't refer to an unparsed entity with an entity reference, but by a name. When you refer to an entity by name instead of with an explicit entity reference, that entity will not be parsed or placed into your XML document directly.|W|P|111827217919307900|W|P|Teach Yourself XML in 21 days, Day 2|W|P|10/25/2005 07:09:00 pm|W|P|Blogger E-A|W|P|Hey, nice blog! I'm definitely going to bookmark you!

Check out my ascii site if you have time: www.ascii.ws

Have Fun.6/07/2005 10:39:00 pm|W|P|CHERUB|W|P|The name of the game in XML is data, because XML is all about storing your data. Unlike HTML, XML is not about displaying your data - it's about packaging that data to transport it easily. All About Markup Languages The term markup refers to codes or tokens you put into a document to indicate how to interpret the (non-markup) data in the document. All About XML XML is a meta-language, which means it's a language that lets you create your own markup languages. W3C publishes its specifications using four types of documents:
Notes; Working drafts; Candidate recommendations; Recommendations.
You're free to make up your own element names in XML, and that's XML's whole power - the capability to create your own markup. Comment that, unlike HTML, the case of a tag is important in XML. XML documents always need a root element, even if they don't have any other elements or text. Being able to create your own elements from scratch has advantages and disadvantages - you're not restricted to a predefined and limited set of tags, but on the other hand, a standard Web browser can understand HTML tags but will have no idea what do with a special tag, e.g.<message>. Looking at XML in a Browser Internet Explorer hasn't done anything more than display raw XML - it hasn't interpreted that XML in any way, because browsers are specialists at displaying data, not interpreting XML tags. One of the most popular reasons for using style sheets with XML is that you store your data in an XML document, and specify how to display that data using a separate document, the style sheet. By seperating the presentation details from the data, you can change the entire presentation with a few changes in the style sheet, instead of making multiple changes in your data ifself. There are 2 kinds of style sheets you can use with XML documents - Cascading Style Sheets (CSS), which you can also use with HTML documents, and Extensible Stylesheet Language style Sheets (XSL), designed to be used only with XML documents. All XML processing instructions start with <? and end with ?>. Working with XML Data Yourself One way of gaining access to that data in a browser is to use JavaScript. Moreover, Java has all kinds of built-in support for working with XML. Structuring Your Data An XML document actually can do more than just hold your data; it can let you specify the structure of that data as well. The software that reads your XML - called an XML processor - is supposed to check your document; if there's a problem, the processor is supposed to quit. It should let you know about the problem, but that's as far as it's supposed to do, according to W3C. There are 2 main checks that XML processors make: checking that your document is well-formed and checking that it's valid. Creating Well-Formed XML Documents Formally, for an XML document being well-formed, it means that the document must follow the syntax rules specified for XML by the W3C in the XML 1.0 recommendation or the XML 1.1 candidatae recommendation. The document must contain one or more elements, and one element, the root element, must contain all the other elements. In addition, each element must nest inside any enclosing elements properly. Creating Valid XML Documents An XML processor will usually check whether your XML document is well-formed, but only some are also capable of checking whether it's valid. An XML document is valid if it adheres to the syntax you've specified for it, and you can specify that syntax in either a Document Type Definition (DTD) or an XML schema. Using a DTD, you're able to specify the syntax your XML document should obey - what elements should be inside what other elements, what attributes an element can have, and so on - and if an XML processor can perform validation, it can check your document and head off problems. How XML is Used in the Real World XML sublanguages like MathML are called XML applications.
Mathematical Markup Language, MathML, was designed to let people embed mathematical and scientific equations in Web pages, which can be found at its W3C's specification. the Amaya browser can support MathML. Chemical Markup Language, CML, lets you view three-dimensional representations of molecules in a Jumbo browser. Synchronized Multimedia Integration Language, SMIL, lets you customize multimedia presentations, which can be found at its W3C's specification. Extensible Hypertext Markup Language, XHTML, makes HTML more rigorous and let you extend it with your own tags. XHTML is HTML 4.01 (the current version of HTML) in XML form. In other words, XHTML is simply an XML application that mimics HTML 4.0 in such a way that you can display the results - true XML documents - in today's Web browsers, as well as extending it with your own new elements. Writing XHTML is a lot like HTML, except that you have to adhere to XML syntax (which means, for example, that every element has a closing tag). HTML+TIME, is another XML application, which was created by Microsoft, Macromedia, and Compaq as an alternative to SMIL for multimedia alternative. Scalable Vector Graphics, SVG, is a W3C-based XML application, which revolves around graphics. However, Microsoft had its own XML-style graphics languages for Internet Explorer, Vector Markup Language, VML, followed by its DirectAnimation tools. The XML-based Simple Object Access Protocol, SOAP, was created to make communication between Web applications easier. SOAP defines a widely accepted lightweight XML protocol that lets you send messages between Web applications, no matter what language such Web applications might have been written in.
Using XML: Mircosoft's .NET Components in .NET use XML to communicate, often even when they're on the same machine. You don't usually see the XML in .NET, but each time you communicate between components, it is there. Online XML Resources W3C's main XML site. The W3C activity page listing what's going on with XML these days. Features a mini-tutorial called "XML in 10 Points". The W3C outline and overview of CSS programming. Packed with XML resources, discussions, and schedules of public events. A free XML tutorial. Microsoft's XML tutorial in ten lessons. An XML tutorial from XMLFiles.com Webdeveloper.com's XML tutorial A comprehensive FAQ list about XML. An XML schema tutorial by Roger L. Costello.|W|P|111818241022577658|W|P|Teach Yourself XML in 21 days, Day 1|W|P|10/02/2005 04:09:00 pm|W|P|Blogger Steve Austin|W|P|Informative blog. I have a xml language blog.10/07/2005 12:50:00 am|W|P|Blogger blaze|W|P|You have a very good site on adsense web site This is something I also have a large interest in and have set up a blog about adsense web site please visit and let me know what you think.10/11/2005 04:50:00 am|W|P|Blogger blaze|W|P|Great info about adsense slut or tit or cock or cunt I have a lage interest also and have a site about adsense slut or tit or cock or cunt please feel free to check it out.10/12/2005 05:53:00 am|W|P|Blogger doer|W|P|Hello, just visited your blog, it's informative. I also have a website related togoogle adsense software. So make sure you visit and hope it's useful.10/18/2005 04:39:00 pm|W|P|Blogger Barney|W|P|Very cool blog you got! I just added you to my bookmarks!

I have a great article resource you might want to check out.10/26/2005 06:16:00 am|W|P|Blogger Gordon|W|P|Hello, just visited your blog, it's informative. I also have a website related togoogle adsense software. So make sure you visit and hope it's useful.10/26/2005 06:28:00 am|W|P|Blogger Google Page Rank 6|W|P|Want more clicks to your Adsense Ads on your Blog?

Then you have to check out my blog. I have found a FREE and Legitimate way that will increase your earnings.

Come Check us out. How to Boost Your AdSense Revenue11/02/2005 08:10:00 am|W|P|Blogger Goodman441|W|P|Does anyone here know of better ways to increase Adsense income? I have been trying to get people to my site at: www.ickaboo.com for some time. Can anyone help me out?