Inline XML – A Checklist Aside

As I sat at my desk a number of days in the past, I all of the sudden puzzled why HTML features a <code> tag, and a <var> tag, and but it takes marking up code no additional than that. It’d be comprehensible to have simply the <code> tag, but when they’re going to
have a <var> tag, shouldn’t they’ve extra programming tags?

Article Continues Under

The eventual product of this line of thought was that the W3C was too
busy to supply a correct code markup contained in the HTML specification,
because the specification has to incorporate a lot else. So in the event that they’re
not going so as to add a correct code markup language, then how would we
mark up our script examples? “Aha!” I assumed to myself. “The proper
probability to make use of XML.”

Why would we use XML right here? The primary cause that I initially wished to
be capable of mark up my instance scripts was in order that I may color-code
their elements for straightforward studying. There are three paths we may
take with the intention to do this.

We may take the trail that websites similar to Zend.com have taken and mark it up with <font>s, however having ditched fonts method again on the freeway, can we wish to waste gas and progress going again to get ’em?
Nah.

Alternatively, we may use <span>s and lessons to mark up all of the
code. Nonetheless, this method is sort of as unhealthy because the <font> one. Sure,
we’re utilizing CSS as a substitute of embedding presentation contained in the
construction, however we’re additionally burying semantic which means inside our class
attribute.

The one different method of marking up this content material is with using
inline XML. By taking this method, we’re:

• Marking content material up by what it means, and letting something that
  browses the doc, human or machine know what that which means is.
• Not cluttering our code up with unneeded characters (<var> is each
  extra concise than <span class=“var”> and extra significant and concise
  than <font shade=“blue”>).
• Permitting ourselves to broaden a tag if we wish to, through attributes (eg <var
kind=“string”>).

Namespaces

Which brings us to the purpose of this text — how one can use a number of
XML languages collectively in a single doc through the use of namespaces.
Let’s say that I wished to mark up a fraction of
code I used to be explaining like so:

<script kind="PHP">
perform layEgg »
  ($measurement, »
   $shade) {
     //No eggs of unfavorable measurement
     if($egg <= 0) {
         return »
  false;
    }
     ...
}

</script>
(Line wraps are marked ».  –Ed.)

Clearly we will’t do it similar to that — if any of our script tags
have the identical identify as our HTML tags then how will we be capable of inform
the distinction between them?


The reply lies with XML namespaces. Do you keep in mind the
xmlns = “http://www.w3.org/1999/xhtml” line
you’ve had so as to add to your HTML tag? That’s an XML namespace, which
has been used to establish that you just’re writing your markup utilizing the
language whose distinctive corresponding url is
http://www.w3.org/1999/xhtml. When you don’t know what I’m speaking
about, the NYPL type information will enlighten you.


Facet word: The xmlns = “http://www.w3.org/1999/xhtml” identifies the
XHTML namespace because the default namespace for all tags which don’t
declare considered one of their very own.


The explanation that you must add this line to your HTML tag is in order that
now you can embrace totally different languages inside your doc, similar to
an XML-based “script markup language,” with out having tag names conflict
with one another. So as to add one other language to your doc you must add
additional namespaces to your HTML tag (word which you can add it to any
component which is an ancestor of the tags which use that namespace,
however it’s best to place all of them on the HTML tag). To do that we
first need to resolve on a novel prefix for these tags — let’s use
“s” for ours. The subsequent factor we want is a novel namespace —  a url
which doesn’t need to level to something. Let’s use http://www.alistapart.com/tales/inlinexml/.
Now, so as to add our new namespace to the doc we add the code
xmlns:s = “http://www.alistapart.com/tales/inlinexml/” subsequent to our different namespace within the
HTML tag.


Placing them to work


Now we've got the namespace declared within the doc tag. The subsequent
factor we have to do is prefix all of the XML tags in our doc with
their distinctive prefix adopted by a colon. The earlier instance now
turns into:


perform layEgg »
  ($measurement, »
  $shade) {
     //No eggs of unfavorable measurement
     if($egg <= 0) {
         return »
  false;
    }
     ...
}



Now that we’ve completed this we will manipulate our XML to show in
numerous colours, through the use of the standard selectors. Be aware that the colon in
the identify should be escaped with a backslash, in order that it isn’t confused
with a pseudo-class (similar to :hyperlink). An instance styling of our code
could possibly be as follows:

<type>
s:script[language="PHP"] {
     shade: black;
}
s:var {
     shade: blue;
}
s:remark {
 shade: inexperienced;
}
...
</type>


Sadly, styling these parts doesn’t work in even some very
current browsers similar to Opera 6/Win. The nice factor is in fact that
all browsers will ignore unknown tags and simply show the textual content
inside them,
so so long as you don’t must format something as a block component,
or in any other case out of the traditional circulation, your XML ought to degrade
completely.

There's a draw back to every thing, and the draw back to together with different XML languages in your XHTML paperwork is that they'll not move validation. This factors extra to an issue with validator companies and DTDs than it does with together with different XML languages inside your XHTML.
The W3C, being conscious of the issue, have issued a number of DTDs which let you mix a number of totally different XML languages collectively in a single doc, similar to XHTML+MathML and XHTML+SVG+MathML. Presumably the authors of different XML languages which may benefit from being included in XHTML will comply with go well with with their very own comparable DTDs.
Within the meantime, authors can nonetheless use the validator to verify that their HTML is written appropriately, ignoring errors in regards to the parts from different namespaces they've included. The opposite path adventurous authors can take is trying to create their very own XHTML variant utilizing the modularisation of XHTML, though correct XML validators fairly than the HTML validator have to be used to validate these paperwork.


Wrapping up


So now you’ve seen how one can declare an XML namespace, and how one can label
its parts inside your paperwork in addition to how one can type them. You
may additionally use JavaScript to govern the tags should you wished to, of
course.
As for different purposes? You’re restricted solely by your creativeness
(and browsers). Why not make and use an inline recipe markup
language, or e-book markup language? What a few purchasing cart markup
language? There are
no limits!


Additional studying