Less is more 
A solution that addresses the needs of all grade levels and all core content areas provides a huge cost savings. The use of one system eliminates the need for different technology configurations, multiple licenses, multiple trainings, support contracts, etc

Put it to the test
No one likes to say we’re teaching to the test, but it’s certainly our job to prepare students to do well on tests. The question is, does your system help all students prepare for all tests? Thousands of dollars can be saved by employing one system that helps prepare all students for the state’s high-stakes exams but also prepares high school students for Advanced Placement tests, exit exams, and the all-important ACT and SAT exams.

Open 24/7/365
Make sure teachers, students, and even parents can easily access your new solution anytime, anywhere

Assessing the situation
Does it allow for customized ad hoc and formative assessments to coincide with teachers’ needs and prescribe activities
to support student-specific learning?

Does it fall in “align?”
Any instructional program, whether supplemental or core, must be aligned to
your state’s standards and scalable to the Common Core State Standards. If you can’t get that automatically without
spending thousands of dollars for upgrades, the solution should receive a failing grade.

Professional development on demand
Be sure to select a program that provides an economical and easy way for teachers to gain skills that can immediately be utilized in the classroom.

A penny saved is a dollar earned
Prices for instructional solutions vary widely, so pay attention to the bang you are getting for the buck

Adding It All Up
Make sure your online learning solution incorporates everything teachers need to effectively
engage learners, inform instructional decisions, and increase student achievement. Without it, there is no ROI.

We make no promises about the latter, but we can definitely improve your odds of achieving the former. To that end, we have identified the most important trends to watch in the year 2011. Before you examine the following pages, however, it is important to understand our definition of an important trend.

You may be tired of hearing about social media, for instance, and you hardly consider it a new development. But if you employ the same social strategies in 2011 as you did in 2010, and fail to account for the changes coming in the next year, your business will suffer the consequences.

Therefore, the most important Web trends in 2011 are those developments that your online business cannot afford to ignore. With that said, here are the trends to which every Web professional should pay close attention in the coming year, as well as some predictions, plenty of solutions and even more instructions along the way.

Everything’s in real time
The developments taking place in real-time technology will impact every industry across the Internet in 2011 from SEO to e-commerce to Web design. Google fired the loudest shot when it introduced Google Instant real-time search in 2010, but versions of the technology have been around for several years.

What are now more significant than the technologies themselves are the many different ways in which they can and will be used. Real-time search, real-time content distribution, real-time ad bidding, real-time analytic and real-time content translation are just some of the areas in which the technologies are changing the Web, thus creating the need for a new set of strategies across the board

To ensure that your website stays ahead of this trend, direct your focus on providing continually fresh and useful content that matters in real time content that addresses the current needs of your audience. There is no better way to achieve this than by engaging with your customers on social networks.

Create and distribute helpful blog posts and informational videos on which users can comment and share with one another, and invite them to write reviews about your products, services and business. Build an application or optimize your website to ensure that users can access your business on their mobile devices and get the information they need right away.

To monitor the engagement, explore some real-time analytic solutions to determine how visitors are interacting with your site while they are on-site. Optics provides just one of the solutions in this rapidly growing space, giving website owners instant analysis that allows them to immediately address the needs of their visitors.

XPath 2.0 functions

In XPath 2.0, three new functions provide support for regular expressions:

• tokenize()
• matches()
• replace()

tokenize()

You use the tokenize() function to split a string into substrings. For example, you can use this function to split a sentence into separate words. The syntax for the tokenize() function is

fn:tokenize( $input as xs:string?,

$pattern as xs:string,

$flags as xs:string) as xs:string+

The fn prefix is used to identify the function as belonging to the XPath 2.0 function namespace – http://www.w3.org/2003/11/xpath-functions. The $input parameter represents the string you want to split, $pattern represents the regular expression you want to use on this string, and $flags is an optional parameter representing a number of predefined options that determine the way the function operates, such as whether it works case sensitively.

matches()

You use the matches() function to return a Boolean value – true or false. If a match exists for the regular expression, a value of true is returned. Otherwise, a value of false is returned. The syntax for the matches() function is

fn:matches( $input as xs:string?,

$pattern as xs:string,

$flags as xs:string) as xs:boolean

The following code example uses the matches() function in an XSL template to identify people with Boston area codes in a list containing customer details. It does this by using a regular expression to test whether a customer’s phone number has an area code of 617. It then outputs those customers’ names in a results table.

<xsl:template match=”customer”>

<table>

<xsl:if test=”matches

(address/phoneNumber, ’617-[0-9]{3}-[0-9]{4}’)”>

<tr>

<td>

<xsl:value-of select=”name/firstName”/>

</td>

<td>

<xsl:value-of select=”name/lastName”/>

</td>

</tr>

</xsl:if>

</table>

</xsl:template>

replace()

The replace() function enables you to search for and replace a string. The syntax for this function is

fn:replace( $input as xs:string?,

$pattern as xs:string,

$replacement as xs:string,

$flags as xs:string) as xs:string

The function accepts an input string, $string, searches it for values represented by $pattern, and replaces these with whatever you specify in the $replacement parameter. As is the case with the tokenize() and matches() functions, $flags is an optional parameter that determines how the function operates.

For example, say you want to ensure that US addresses in customer lists are always displayed as “U.S.A.” rather than “USA” or “US”. The following XSL code searches for alternative address formats and replaces them with U.S.A..

<xsl:for-each select=”address/country”>

<xsl:value-of select=”replace

(., ‘[Uu]\.?[Ss]\.?[Aa]?\.?$’, ‘U.S.A.’)”/>

</xsl:for-each>

The structure of an XBRL GL document

This diagram shows the basic structure of an XBRL GL document.

The top-level element of an XBRL GL document, which appears directly after the XBRL instance document root element, is accountingEntries, which is a tuple.

The documentInfo element appears directly after accountingEntries, and provides information about all the data in the file.

The documentInfo element has several child elements. One of the most important is entriesType, which has several predefined values that specify the purpose of the XBRL GL instance document, such as whether it is a ledger or a list of assets.

The entityInformation element holds information about the reporting organization and the entryHeader element is the parent element that describes all the entry or journal entry headers, as well as containing the elements that hold the financial data in the document.

The entryHeader element has a number of child elements. The most important is entryDetail, which is the parent element for each ledger entry. It, in turn, has several child elements, including account, documentType, debitCreditCode, and amount.

The instance document
XBRL GL instance documents may vary in structure depending on whether they use the XBRL GL 1.0 or 1.1 taxonomies. Whereas the XBRL GL 1.0 taxonomy uses a single schema and three linkbase documents, the XBRL GL 1.1 uses four additional schema and many additional linkbases. So although it uses the same core elements as version 1.0, it also defines new elements and requires the use of additional namespace prefixes to
qualify these. For example, instead of using glc as the XBRL GL recommended namespace prefix, it uses gl-cor, which identifies elements from the core schema. Here is a section of an XBRL GL instance document based on the version 1.1 taxonomy. Because the XBRL specification used by this taxonomy is version 2.0 rather than version 2.1, the root element is group rather than xbrl.

<?xml version=”1.0″ encoding=”UTF-8″?>
<xbrli:group
xmlns:link=”http://www.xbrl.org/2001/XLink/xbrllinkbase”
xmlns:xbrli=”http://www.xbrl.org/2001/instance”
xmlns:xhtml=”http://www.w3.org/1999/xhtml”
xmlns:gl-plt=”http://www.xbrgl.com/gl-plt/”
xmlns:gl-cor=
“http://www.xbrl.org/taxonomy/int/gl/cor/2003-08-29/”
xmlns:gl-bus=
“http://www.xbrl.org/taxonomy/int/gl/bus/2003-08-29/”
xmlns:gl-muc=
“http://www.xbrl.org/taxonomy/int/gl/muc/2003-08-29/”
xmlns:gl-usk=
“http://www.xbrl.org/taxonomy/int/gl/usk/2003-08-29/”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:ISO4217=”http://www.xbrl.org/2003/iso4217″
xsi:schemaLocation=
“http://www.xbrlgl.com/gl-plt/ XBRLGL.xsd”>
<gl-cor:accountingEntries>
<gl-cor:documentInfo>
<gl-cor:entriesType nonNumericContext=”s1″>
entries
</gl-cor:entriesType>
<gl-cor:language nonNumericContext=”s1″>

ISO693:ja
</gl-cor:language>
<gl-cor:creationDate nonNumericContext=”s1″>
2002-06-18
</gl-cor:creationDate>
<gl-cor:entriesComment nonNumericContext=”s1″>
XXX-FI
</gl-cor:entriesComment>
</gl-cor:documentInfo>
<gl-cor:entryHeader>
<gl-cor:enteredBy nonNumericContext=”s1″>
001
</gl-cor:enteredBy>
<gl-cor:enteredDate nonNumericContext=”s1″>
2001-04-01
</gl-cor:enteredDate>
<gl-cor:sourceJournalID nonNumericContext=”s1″>
se
</gl-cor:sourceJournalID>
<gl-cor:entryNumber nonNumericContext=”s1″>
4
</gl-cor:entryNumber>
<gl-cor:entryDetail>
<gl-cor:account>
<gl-cor:accountSub>
<gl-cor:accountSubType
nonNumericContext=”s1″>
division
</gl-cor:accountSubType>
<gl-cor:accountSubID
nonNumericContext=”s1″>
001
</gl-cor:accountSubID>
<gl-cor:accountSubDescription
nonNumericContext=”s1″>
Tokyo Head Office
</gl-cor:accountSubDescription>
</gl-cor:accountSub>

Summary
As summary, An XBRL taxonomy is a document or set of documents defining a specific information set that can be reported using the XBRL specification. Financial reporting taxonomies are created specifically for individual regions or companies but the XBRL General Ledger
taxonomy (XBRL GL) is a widely applicable standard taxonomy. XBRL GL provides a structure for presenting any accounting information in an XBRL report, collecting all general ledger receivables and payables, and presenting them in a traditional reporting format.

Financial reporting taxonomies
Because accounting standards and business requirements vary between regions and organizations, financial reporting taxonomies are created specifically for individual regions, industries, or even companies. To improve the usability of taxonomy documents, XBRL International specifies recommended taxonomy design architecture guidelines on its web site.

General Ledger taxonomy The XBRL General Ledger taxonomy (XBRL GL) is a standard taxonomy that is more widely applicable than financial reporting taxonomies. It is also known as the Journal taxonomy. XBRL GL provides a structure for presenting any accounting information in an XBRL report. It collects all general ledger receivables and payables and represents them alongside inventory information in a traditional reporting format. Because it deals with general ledger entries rather than industry or region-specific terms, it is reportingindependent, unlike financial reporting taxonomies.

XBRL GL can also be used to present non-financial information found in an accounting system and it enables legacy accounting charts of accounts to be presented in a standardized way.

XBRL GL is system-independent and can handle imported data from any accounts application or operating system. It also facilitates the transfer of general ledger data from one system to another.

Applying the General Ledger taxonomy to an XBRL document
The latest release of XBRL GL is the draft version of release 1.1, which includes schemas and linkbases that handle business and inventory metrics as well as the general ledger. XBRL GL 1.0 is the approved version. To apply XBRL GL 1.0 to an instance document, you reference the namespaces shown in the following table.

XBRL GL Namespaces

XBRL GL also uses the standard XHTML and XLink namespace URIs – http://www.w3.org/1999/xhtml and http://www.w3.org/1999/xlink. Versions 1.0 and 1.1 of the XBRL GL taxonomy schemas can be downloaded from the XBRL organization’s web site.

Following next, we shall talk about “The structure of an XBRL GL document” in Examining an XBRL taxonomy [Part 2], coming up next. If you are looking for some XBRL training, you can look for computer institute like CSI Chicago offers special classes and computer certifications about this.

XML Signature Standard
The W3C XML Signature standard provides a specification for creating and using digital signatures in XML. You use XML Signature to provide authentication when transmitting documents. You can use XML Signature with any content, including XML data. You can sign just a portion of a document, in the same way that you can encrypt just part of it.

Authenticating XML documents is difficult, however, because their structure may change even when the data in them does not. Most digital signature methods treat the structure of a document as significant when generating the unique value, or message digest, that can be used to validate the document’s authenticity To address this, the W3C uses XML Canonicalization. This specification defines how to generate a canonical form of an XML document. This is a highly formalized version of the XML document. Two XML documents that differ textually as a result of comments, empty tags, or line breaks for example, but have the same logical structure will produce identical canonical documents.

The basic structure of a digital signature is as follows, where ? indicates zero or one occurrence and * indicates zero or more occurrences:

<Signature ID?>
<SignedInfo>
<CanonicalizationMethod/>
<SignatureMethod/>
(<Reference URI? >
(<Transforms>)?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo>)?
(<Object ID?>)*
</Signature>

Signature is the root element, and its ID attribute is an optional one used to identify the signature. The mandatory SignedInfo element represents the data that is signed. Then the CanonicalizationMethod element provides the canonicalization algorithm that has been applied to the signed data. The Reference element provides a reference to the data object being signed. This element contains the Transforms, DigestMethod, and DigestValue child elements, which describe how the signed data object has been compiled. The KeyInfo element enables you to obtain the key to validate the signature. Note that, although this element is qualified when used in encryption, it does not need to be qualified when used with digital signatures because it is part of the digital signature namespace.

The following is an example of a signature:

<Signature Id=”ENTSecureSig”
xmlns=”http://www.w3.org/2000/09/xmldsig#”>
<SignedInfo>
<CanonicalizationMethod Algorithm=
“http://www.w3.org/TR/2001/REC-xml-c14n-20010315″/>
<SignatureMethod Algorithm=
“http://www.w3.org/2000/09/xmldsig#dsa-sha1″/>
<Reference URI=
“http://www.w3.org/TR/2000/REC-xhtml1-20000126/”>
<DigestMethod Algorithm=
“http://www.w3.org/2000/09/xmldsig#sha1″/>
<DigestValue>
j6lwx3rvEPO0vKtMup4NbeVu8nk=
</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=…</SignatureValue>
<KeyInfo>
<KeyValue>
<DSAKeyValue>
<P>…</P><Q>…</Q><G>…</G><Y>…</Y>
</DSAKeyValue>
</KeyValue>
</KeyInfo>
</Signature>

The Signature element declares the XML Signature namespace. The Reference element identifies the W3C XHTML specification as the object that’s being signed in this case. The DigestMethod element’s Algorithm attribute indicates that the SHA-1 algorithm was used to generate a hash, or message digest of this, the value of which is indicated in DigestValue. Everything within the SignedInfo element is canonicalized according to the Canonical XML specification indicated by the CanonicalizationMethod element. Then the DSA algorithm specified by the Algorithm attribute in SignatureMethod is used to produce the SignatureValue, which is the digest of everything in the SignedInfo element. KeyInfo specifies what key should be used to validate this signature – in this case, DSA keys. The P, Q, G, and Y elements are used only with DSAKeyValue and specify DSA public key values.

For this signature to be validated, the contents of SignedInfo must be canonicalized, and then processed with the algorithm specified in SignatureMethod using the public key supplied by KeyInfo. If the value this produces matches the one in SignatureValue, the signature is valid. For the signed data to be validated, its unsigned version is retrieved using the Reference URI, processed according to DigestMethod, and compared to the value in DigestValue.

As a summary on Encrypting and authenticating of XML data, XML Encryption enables you to encrypt an entire document, a specific element, or the content of a specific element. It also facilitates the transmission of data between more than two parties and ensures end-to-end security rather than party-to-party security. XML Signature provides authentication when using web services. It enables users to receive data that is signed by the sender and to verify the integrity of the data.

XML Encryption encrypts data using the following elements – EncryptedData, CipherData, CipherValue, CipherReference, and EncryptionMethod. These elements are in the http://www.w3.org/2001/04/xmlenc# namespace. XML encryption is key-based and can be asymmetric or symmetric.

The W3C XML Signature standard provides a specification for creating and using digital signatures in XML. You can sign just a portion of a document, in the same way that you can encrypt just part of it. XML Signature relies on XML Canonicalization to generate a canonical form of an XML document. This ensures that the data in a document can still be verified even if its structure changes.

Tag wars
In the early days of the Web, HTML proved to be an extremely popular authoring language. With HTML, publishing content to the Web was easy – you inserted some tags into a document using a text editor and uploaded the document to a web site, where it could be read by anybody with a browser. However, this very simplicity was a drawback, because the people who were actually developing web browsers wanted to include exciting new features that were not supported by early versions of HTML. So these developers decided to create their own tags, which could only be interpreted properly by their browsers. This threatened to lead to a situation where the type of web page you could visit would depend on the browser you were using. Clearly what was needed was an agreed HTML standard.

The W3C to the rescue
The need for a body to develop common standards for the Web led to the formation, by Tim Berners-Lee in 1994, of the World Wide Web Consortium (W3C). A specification that has been approved by members of the W3C and is appropriate for widespread use is published as a recommendation document.

One of the most important initial tasks for the W3C was to develop a standard for HTML, and in 1995 this body was busily working on HTML 3.0, a badly needed update for the two previous versions – HTML 1.0 and HTML 2.0. However, the draft specification for HTML 3.0 included many new tags, most of which were not, and would not, be supported by browsers available at the time. So the W3C changed tack – instead of attempting to cram in lots of new features, it focused on what was currently supported. HTML 3.0 was abandoned and, in 1996, the W3C published its recommendation for HTML 3.2, which represented the consensus on HTML at that time.

The next recommendation after HTML 3.2 described the widely used HTML 4.0, released in 1997, and was followed in 1999 by a recommendation for HTML 4.01.

The latest recommendation – XHTML 1.0
XHTML 1.0 is W3C’s recommendation for the latest version of HTML. XHTML 1.0 is a hybrid of XML – another, more powerful markup language called the Extensible Markup Language – and HTML 4.01. XHTML 1.0 is specified in three “flavors”:

• XHTML 1.0 Transitional – if you are a developer creating web pages for the general public, you should use this “flavor” because it allows you to take advantage of XHTML features such as Cascading Style Sheets, and you only have to make small changes to your documents to accommodate users viewing your pages with older browsers that don’t support XHTML
• XHTML 1.0 Strict – this is used when you want your document to be free of any tags associated with the layout of text
• XHTML 1.0 Frameset – this is useful when you want to use HTML Frames to partition the browser window into two or more frames

Watch out for old tags
If you read the documentation for XHTML 1.0, you will see that some tags and attributes are deprecated – which means that, although they are supported in XHTML 1.0, they may not be supported in future versions. As a result, you are strongly urged not to use the deprecated tags and attributes on the list provided by the W3C.

However, one of the difficulties is that some browsers may not support the tag that replaces a deprecated one. For example, in XHTML 1.0, the <applet> tag is deprecated in favor of <object>, but recent versions of Netscape Navigator do not support <object>. In this case, you may be forced to use <applet>, even though it is not recommended.

Return of the tag wars – proprietary extensions
You might think that with the release of XHTML 1.0, everybody is happy – that all web site developers adhere to this specification when creating web pages and all browsers provide full support for this code. Nothing is ever this neat, however, and browser developers have included features that are not part of the current recommendation. These features are called proprietary extensions, because they supposedly “extend” the existing standard, although in most cases it’s possible to adhere to the current recommendation and develop the features that these extensions offer.

Two (in)famous proprietary extensions are the <marquee> and <blink> tags. Neither is part of XHTML 1.0, and in any case both are browser-specific – the <marquee> tag is supported by Internet Explorer but not by Netscape Navigator, and the <blink> tag is supported by Netscape Navigator but not Internet Explorer. For these and other reasons, such extensions should be avoided.

Stick to the recommendation and check your code
When creating web pages, it’s always a good idea to conform to the latest recommendation from the W3C, who will even check any code you send them to see if it is valid. And you should test any pages you develop with several browsers and older versions of these browsers.

Using encryption and authentication with web services
As web services become more prevalent, the issue of security becomes more important. Encryption and authentication are vital tools for achieving secure web services.

Security protocols such as Transport Layer Security (TLS) and Secure Sockets Layer (SSL) enable you to encrypt data and transmit it safely over the Internet. However, these protocols have a number of shortfalls, in that they provide security only between the two parties sending and receiving data at a particular moment in a transaction, rather than among all the parties in a multi-part online information exchange. For example, SSL can encrypt all details of an online purchase you make. This ensures that your credit card number is encrypted when sent to an online merchant, but it cannot ensure that the merchant then sends the number securely to a credit card verification service. XML Encryption serves to address these shortfalls. It enables you to:

• encrypt specific parts of the data being transmitted
• provide end-to-end security

This means that you can choose to encrypt an entire document, a specific element, or the content of a specific element. For example, in an online transaction, you may need to encrypt the credit card details, but not the product details. In this case, you would encrypt a specific element or the content of a specific element rather than encrypting the entire document. You can also transmit data between more than two parties and ensure end-to-end security rather than party-to-party security. This provides opportunities for more advanced e-commerce applications.

Digital signatures provide authentication when using web services. They enable users to receive data that is signed by the sender and to verify the identity of the sender and the integrity of the document – that is to verify that the data has not been altered since it was sent.

Encryption and authentication can be used together to provide powerful security solutions. The W3C has published recommendations for both encryption and digital signatures using XML. However, these are only specifications. They do not provide implementation details. To implement XML Encryption or XML Signatures, you’ll need to create programs that use these standards.

Encrypting data using XML
The W3C’s XML Encryption standard provides a way to encrypt any data. That data can be an entire document, a specific element, or the content of an element. Also, it doesn’t necessarily have to be XML. The standard then specifies a way to create an XML document to store the encrypted data.

Data is encrypted using the following elements – EncryptedData, CipherData, CipherValue, CipherReference, and EncryptionMethod.

Encrypted data generally takes the following format, where ? indicates zero or one occurrence and * indicates zero or more occurrences of an element or attribute:

<EncryptedData Id? Type? MimeType? Encoding?>
<EncryptionMethod/>?
<ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
<ds:RetrievalMethod>?
<ds:*>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties>?
</EncryptedData>

The EncryptedData element identifies the section of an XML document that holds encrypted information. If an entire document is encrypted, this element will serve as the root element for the encrypted document. The EncryptedData element can have the following child elements – EncryptionMethod, ds:KeyInfo, CipherData, and EncryptionProperties. The EncryptionMethod element specifies the encryption algorithm used. The ds:KeyInfo element contains information on the key used to encrypt and decrypt the data. For example, it can provide the public key that was used for encryption.

The CipherData element can contain a CipherValue or a CipherReference element. The CipherValue element contains the encrypted data, whereas the CipherReference element provides a URI describing the location of the encrypted data. Finally, the EncryptedData element can contain an optional EncryptionProperties element, which describes the properties of the encrypted data, such as when it was generated.

For example, say you want to encrypt the following document:

<?xml version=”1.0″ ?>
<booking
xmlns=”http://www.easynomadtravel.com/securebookings”>
<vacation>
<destination>Acapulco</destination>
<startDate>2004-05-14</startDate>
<endDate>2004-05-28</endDate>
</vacation>
<customer>
<name>Jonathan Gold</name>
<creditCard>
<cardNumber>1234898888999968</cardNumber>
<cardType>VISA</cardType>
<validTo>2005-01-31</validTo>
<creditCard>
</customer>
</booking>

Encrypting the entire file would result in the following code:

<?xml version=”1.0″ ?>
<EncryptedData xmlns=”http://www.w3.org/2001/04/xmlenc#”
MimeType=”text/xml”>
<CipherData>
<CipherValue>A23B45C56</CipherValue>
</CipherData>
</EncryptedData>

All of the encrypted data is contained within the EncryptedData element. This element is in the XML Encryption namespace, whose URI is http://www.w3.org/2001/04/xmlenc#, and whose recommended namespace prefix is xenc. The MimeType attribute specifies the format of the original data. Note that the CipherValue in this example is a sample. A real CipherValue would probably be considerably longer.

Encrypting the creditCard element only would result in a document such as:

<?xml version=”1.0″ ?>
<booking
xmlns=”http://www.easynomadtravel.com/securebookings”>
<vacation>
<destination>Acapulco</destination>
<startDate>2004-05-14</startDate>
<endDate>2004-05-28</endDate>
</vacation>
<customer>
<name>Jonathan Gold</name>
<EncryptedData Type=
“http://www.w3.org/2001/04/xmlenc#Element”
xmlns=”http://www.w3.org/2001/04/xmlenc#”>
<CipherData>
<CipherValue>A23B45C564587</CipherValue>
</CipherData>
</EncryptedData>
</customer>
</booking>

Only the encrypted creditCard element is contained in the EncryptedData element. All other elements in the document are visible. Once again, the EncryptedData element uses the http://www.w3.org/2001/04/xmlenc# namespace. However, this time it also uses the Type attribute with the value http://www.w3.org/2001/04/xmlenc#Element. Note the word Element at the end of the URI. This indicates that an element is encrypted.

Alternatively, you could encrypt just the credit card number, in which case the resulting document would be as follows:

<?xml version=”1.0″ ?>
<booking xmlns=
“http://www.easynomadtravel.com/securebookings”>
<vacation>
<destination>Acapulco</destination>
<startDate>2004-05-14</startDate>
<endDate>2004-05-28</endDate>
</vacation>
<customer>
<name>Jonathan Gold</name>
<creditCard>
<cardNumber>
<EncryptedData Type=
“http://www.w3.org/2001/04/xmlenc#Content”
xmlns=”http://www.w3.org/2001/04/xmlenc#”>
<CipherData>
<CipherValue>A23B45C564587</CipherValue>
</CipherData>
</EncryptedData>
</cardNumber>
<cardType>VISA</cardType>
<validTo>2005-01-31</validTo>
<creditCard>
</customer>
</booking>

This time all tags remain visible. Only the content of the cardNumber element has been encrypted. Again, the EncryptedData element uses the http://www.w3.org/2001/04/xmlenc# namespace. However, it uses the following value for the Type attribute – http://www.w3.org/2001/04/xmlenc#Content. The word Content at the end of this URI indicates that the content of an element is being encrypted.

XML encryption is key-based. Key-based encryption can be asymmetric or symmetric. Asymmetric encryption uses public and private keys. You use an algorithm to generate both keys. Then you send your public key to anyone who wants to send encrypted data to you. They use the public key to encrypt the data and then send the encrypted data to you. Then you use your private key to decrypt the data. Symmetric encryption uses secret keys. Using symmetric encryption, you exchange a secret key with someone who wants to send encrypted data to you. Then you can both use the secret key to encrypt and decrypt data.

In a document that uses encryption, the ds:KeyInfo element contains information about the key:

<ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
<ds:RetrievalMethod>?
<ds:*>?
</ds:KeyInfo>?

Note that these elements use the ds namespace prefix because they occur in the XML Signature namespace rather than in the XML Encryption namespace. For example,

<EncryptedData xmlns=”http://www.w3.org/2001/04/xmlenc#”
Type=”http://www.w3.org/2001/04/xmlenc#Element”/>
<EncryptionMethod Algorithm=
“http://www.w3.org/2001/04/xmlenc#tripledes-cbc”/>
<ds:KeyInfo xmlns:ds=
“http://www.w3.org/2000/09/xmldsig#”>
<ds:KeyName>Jonathan Gold</ds:KeyName>
</ds:KeyInfo>
<CipherData>
<CipherValue>A23B45C564587</CipherValue>
</CipherData>
</EncryptedData>

The KeyInfo and KeyName elements are qualified to indicate they belong to the XML Signature namespace.

The data in this code sample has been encrypted using the Triple DES algorithm. This is specified using the Algorithm attribute in the EncryptionMethod element:

<EncryptionMethod Algorithm=
“http://www.w3.org/2001/04/xmlenc#tripledes-cbc”/>

The KeyInfo element declares the XML Signature namespace:

<ds:KeyInfo xmlns:ds=
“http://www.w3.org/2000/09/xmldsig#”>

Triple DES uses symmetric keys, and the KeyName element is used here to indicate that the key used is Jonathan Gold’s.

<ds:KeyName>Jonathan Gold</ds:KeyName>

Alternatively, you could use the AES algorithm to encrypt the data:

<EncryptedData Id=’ED’
xmlns=’http://www.w3.org/2001/04/xmlenc#’>
<EncryptionMethod Algorithm=
‘http://www.w3.org/2001/04/xmlenc#aes128-cbc’/>
<ds:KeyInfo xmlns:ds=
‘http://www.w3.org/2000/09/xmldsig#’>
<ds:RetrievalMethod URI=’#EK’
Type=”http://www.w3.org/2001/04/xmlenc#EncryptedKey”/>
<ds:KeyName>Antonia Suares</ds:KeyName>
</ds:KeyInfo>
<CipherData>
<CipherValue>A23B45C564587</CipherValue>
</CipherData>
</EncryptedData>

This time the value of the Algorithm attribute in the EncryptionMethod element is http://www.w3.org/2001/04/xmlenc#aes128-cbc, to indicate 128-bit AES. The RetrievalMethod element is used to identify KeyInfo information that is stored remotely.

The ‘HT’ part – hypertext
Hypertext – invented by Ted Nelson in the 1960s – is really a special type of database format in which individual documents can be linked to each other in any number of ways. The links between different documents are called hyperlinks – these are the embedded instructions within a document that link it to another document. On the Web, hyperlinks are typically indicated by blue text. When you click the blue text, you are brought to another related file or web page.

As its name implies, the World Wide Web is a single huge hypertext system in which an enormous amount of individual web pages are connected by an enormous number of hyperlinks. Of course, most web pages include other media elements besides text, such as graphics, animation, and audio, so the Web is more accurately described as a hypermedia system.

The ‘M’ – markup
Markup refers to the characters or symbols that you place within a document to determine how the document will look when printed or displayed. Markup indicators can also give a document its logical structure.

In HTML, these indicators are usually called tags, which are the characters or words enclosed in angle brackets that you can see in any HTML document if you open it in your browser and select View – Source (Internet Explorer) – or View – Page Source (Netscape Navigator).

Opening tags mark the start of the tagged part of the document affected by the tag and have a pair of angle brackets <>, whereas closing tags, which mark the end of the tagged section, have a forward slash within a pair of angle brackets </>. Characters inside the brackets determine what the tag actually does. So, for example, these are the opening <b> and closing </b> bold tags. If you surround some text in an HTML document with the <b> and </b> tags, the text inside the tags will be displayed as bold if the document is opened by an HTML interpreter, such as a web browser. Other common tags include the opening <body> and closing </body> tags for marking the body of a document, the opening <ul> and closing </ul> tags for bulleted lists, and the opening <tr> and closing </tr> table row tags.

You can also add hyperlinks to your document by using the opening <a href = “URL”> and closing </a> tags, where URL is the address of the web page or resource that will be opened or called when the user clicks the link. In essence, HTML is the set of markup indicators, or tags, that you can insert into a file so that it can be displayed as a web page.

People said

No matter black cat or white cat, as long can catch mouse is a good cat.

For me,

No matter is Big Search Engine or Small Search Engine, new or old, famous or non famous, as long can bring me traffic is a GOOD Search Engine.

Recently I come across this new Search Engine name BING.com; this SE belong to Microsoft, basically the algorithm are almost same with their others SE, such as live.com and msn.com. (I guess).

A lot of blogger blog about this Search Engine, but non of them show how to submit your website to this Bing.com Search Engine… Well,without talking much, let this Malaysia LIFE Tech Blog show you what is call LIFE blogging

Here the URL you need.

http://www.bing.com/docs/submit.aspx

Ok, without talking much, lets submit our website togetgher. If you feel not enough to submit only for 1 Search Engine, here have a list of major search engine in the world. Let Submit URL to Search Engine.