html tags within meta tags allowed?

[Donald Firesmith]

Are html tags allowed within meta tags? Specifically, if I have html
tags within a <definition> tag within XML, can I use the definition as
the content within the <meta content="description> tag? If not, is
there an easy way to strip the html tags from the <definition> content
before inserting the content into the meta tag?

 

[Klaus Johannes Rusch]

Are html tags allowed within meta tags? Specifically, if I have html
tags within a <definition> tag within XML, can I use the definition as
the content within the <meta content="description> tag? If not, is
there an easy way to strip the html tags from the <definition> content
before inserting the content into the meta tag?

An attribute cannot contain elements, you can easily extract the text
only by using

<xsl:value-of select="normalize-space(description)" />

 

[Andy Dingley]

Are html tags allowed within meta tags?

Learn the difference between tags, elements and attributes.

Specifically, if I have html
tags within a <definition> tag within XML, can I use the definition as
the content within the <meta content="description> tag?

Let's rephrase that as "Can I represent the content of one element as
the content of an attribute of another element ?"

In that case, then yes you can - with the proviso that you need to be
careful about the meaning of "represent". The content models of
elements and attributes are different, so you can't just "place" that
of any element into an attribute, as it might contain the "<>"
characters that mark out a tag (and are not permitted in attributes).

But you can represent this, with a process known as entity encoding.
The "awkward" characters <>&' are replaced with their entity encoded
representations of &lt; &gt; &amp; & &apos;

Note that you have now done something "outside" of XML. XML does
_not_ (and cannot) know what you've done, or that the contents of the
destination element's attribute should be de-encoded on reading. It's
a simple process to do, but it's not simple for the recipient to
"know" that it ought to do this. there is _no_ way for "an XML tool"
to recognise that it ought to - after all, the content is well-formed
XML either way, it's just a question of interpreting its meaning.

A common case where this is done is with RSS (although that's just put
into another element, not an attribute) Because most of the RSS specs
are so poorly written, there is great confusion here.
http://diveintomark.org/archives/2004/02/04/incompatible-rss

This is thus why in your literal example you _can't_ do what you're
trying to do. Yes you could do it, but no you shouldn't. It is not
"meaningful" (in the sense of understanding, not the sense of XML) to
place encoded content, or anything resembling HTML or XML tags into
the content attribute of a HTML <meta> element. The readers of it (of
which there are very few) just aren't expecting to see it in there and
they won't know what to do with it. They certainly won't have the
action you're optimistically hoping for, sensible though that might
have been (had we all know what the game was and how to play along).

 

[Donald Firesmith]

Learn the difference between tags, elements and attributes.





Let's rephrase that as "Can I represent the content of one element as
the content of an attribute of another element ?"

In that case, then yes you can - with the proviso that you need to be
careful about the meaning of "represent". The content models of
elements and attributes are different, so you can't just "place" that
of any element into an attribute, as it might contain the "<>"
characters that mark out a tag (and are not permitted in attributes).

But you can represent this, with a process known as entity encoding.
The "awkward" characters <>&' are replaced with their entity encoded
representations of &lt; &gt; &amp; & &apos;

Note that you have now done something "outside" of XML. XML does
_not_ (and cannot) know what you've done, or that the contents of the
destination element's attribute should be de-encoded on reading. It's
a simple process to do, but it's not simple for the recipient to
"know" that it ought to do this. there is _no_ way for "an XML tool"
to recognise that it ought to - after all, the content is well-formed
XML either way, it's just a question of interpreting its meaning.

A common case where this is done is with RSS (although that's just put
into another element, not an attribute) Because most of the RSS specs
are so poorly written, there is great confusion here.
http://diveintomark.org/archives/2004/02/04/incompatible-rss

This is thus why in your literal example you _can't_ do what you're
trying to do. Yes you could do it, but no you shouldn't. It is not
"meaningful" (in the sense of understanding, not the sense of XML) to
place encoded content, or anything resembling HTML or XML tags into
the content attribute of a HTML <meta> element. The readers of it (of
which there are very few) just aren't expecting to see it in there and
they won't know what to do with it. They certainly won't have the
action you're optimistically hoping for, sensible though that might
have been (had we all know what the game was and how to play along).

Okay. Then what are you supposed to do in the following situation?
Assume that you have over 1000 items that you want to document using
XML instead of HTML. For the foreseeable future, you will use them to
generate webpages primarily for human consumption. You are mainly
converting from HTML to XML so that you can build tools that help you
select and tailor the contents of these 1000 items.
Each of these items has one or more of several kinds of parts. These
parts vary from item to item and you want to be able to pull out the
content of these variable parts into XML so that you can use XSL to
capture the common standard structure and contents. However, the
variable parts are more complex than simple prices, model numbers, etc.
They have enough variablity to include links, optional sublists, and
other information that requires proper formatting that appears not to be
able to be captured in a single XSL. That is why you want to include
the HTML tags. Specifically, check out the 1,100+ free open source
reusable process components within the OPEN Process Framework repository
at www.donald-firesmith.com. If you look at several examples of the
same metatype, you will quickly see the kind of variability I am talking
about. So far, I have created activity DTD and XSL files and an XML
file for the requirements engineering activity. I am sure that they are
probably not the world's best examples of XSL and XML style. But I am
not sure how to improve them and still retain the desired look and feel
of the resulting XHML webpages. I would be happy to send anyone who is
interested the three example files and would greatly appreciate any
recommendations, especially if these recommendations are specific and
even more so if they come back in the form of modified DTD, XSL, and/or
XML files. The examples I see in the books are always very simple and
far more standardized that the HTML that I am trying to transform into XML.
By the way, the OPEN Process Framework Repository Organization is a
non-profit volunteer organization with no funding to pay for a
consultant to do the conversion for us. That is why we are relying on
groups such as this one to help us do a good job.

Donald Firesmith
Chair, OPEN Process Framework Repository Organization

 

[Peter Flynn]

Donald Firesmith wrote:

[snip]

Okay. Then what are you supposed to do in the following situation?
Assume that you have over 1000 items that you want to document using
XML instead of HTML.

Put them all into XML. Natively. Don't try to preserve HTML within XML,
make it *all* XML. You can trivially convert data back to HTML when you
create the Web pages if it's been properly marked up in the first place.
The "proper formatting" can then be a function of the XML markup.

///Peter

 

[Andy Dingley]

Okay. Then what are you supposed to do in the following situation?

There are two levels at which you have to think.

First of all is a project management level. You're putting a big new
system together and you're doing it with a wide range of new tools.
You need to understand these tools before using them - otherwise your
chosen design might be rather less than ideal....

Of course, a budget would allow you to hire in some help at this
point. I can tell you that a few days of my consultancy rates are
_much_ cheaper than a few months of my grunt coder rates trying to fix
it afterwards. Not that any project manager ever listens, oh no.

The second level is that of the design itself. Much of this is based
around toolsets or platforms, both those that are appropriate and
those particularly familiar from past experience. XLink is probably
relevant to you, XSL:FO isn't. Are you a Java & Unix shop, or a M$oft
gulag ?

It's typical of XML that the tools chosen aren't particularly
problem-specific. I can sketch out a rough architecture for you, and
the tools you need to look at, and this will be the same whether
you're describing your knowledge-based virtual product, or tins of
beans in a supermarket. It's a bottom-up design process - the tools
are chosen by your need to publish in HTML, and your entities' need to
represent their inter-linkage, not what the entity itself is about.

Assume that you have over 1000 items that you want to document using
XML instead of HTML. For the foreseeable future, you will use them to
generate webpages primarily for human consumption. You are mainly
converting from HTML to XML so that you can build tools that help you
select and tailor the contents of these 1000 items.

Been there, done that, have an entire wardrobe of conference t-shirts
on the subject.

Ditch the HTML fixation. HTML has three good things about it; it's the
thing to use for final-stage publishing because it gives you
web/intranet access at very low cost. It's familiar to many people for
authoring, so you can use it as an internal lightweight text editing
format and capitalise on much existing experience. It also has some
features for representation of text formatting and some _minimal_
features for representing links.

On the other hand, it's not what you need for the internal
representation of abstract data. There are uses for it in the external
interface, but no needs for it in the internal representation. In
patrticular, choosing HTML as the basis for your link representation
is going to be a whole world of pain. Forget using HTML to represent
your links. Look at XLink instead (a bunch of properties you'd place
on one of your other elements).

For HTML, use XHTML. Trust me. You can always make it into HTML 4.01
at the last moment, but keeping your internal data stream as XML-clean
not HTML or SGML is a big saving of effort.

I'd suggest Schema over DTD, and possibly looking at OWL.

In general, don't invent a new schema but assemble one from
pre-existing and widespread standards. Namespacing is useful here.
You will probably need to invent _some_ schema, but this can be very
minimal - just a container for properties that are described by
pre-existing schemas.

Look into Dublin Core, particularly the qualified form. You can do an
awful lot with just this much, and it gives you useful benefits to
external publishing in a vaguely communicable format.

For representing text markup, then you can use either HTML or DocBook.
I don't particularly like either, but not using one of them is a brave
decision that would require some real justification. Both are bloated
by legacy features (especially DocBook), neither are particularly
powerful in a general sense.

XSLT can do nearly everything you need here, including the
construction of all the linkage in external HTML that you might ever
wish. XSLT isn't the general solution to everything that is often
claimed, but it'll do you here.


If it were me, I'd use RDF instead of XML. It has advantages for this
sort of meta-description problem. These are mainly in the ability to
build such a system and then exchange its data with external systems
in a fairly easy manner.

XML is _very_ low-level. You have no implied data model to it. until
you build one with schema. RDF gives you a little more than this, and
it gives it to everyone in a consistent and commonly shared manner.
There are objects (with implied notions of identity) and they can have
properties. these properties can in turn have type, which may be
shared between different properties. Type in turn may be used to imply
values being members of a controlled vocabulary.

A controlled vocabulary for your properties is an excellent thing to
have, and OWL is a useful way to express them.




As to publishing in HTML, then this is easy but also trivial. Your
original question of how to publish structured content in the
attributes of a <meta> element is well-intentioned but somewhat
misguided. You can publish here, but there's nothing that will look at
it to try and read it.

HTML, as an output authoring medium is for human readable use only.
(this sucks, but make the most of it). Forget trying to publish really
complex machine-processable metadata by it.

If you really wish to, look at the well-desciribed techniques for
embedding Dublin Core within HTML (this is as far as one can
practically go these days). To push things further, even though it's
still optimism rather than consumer demand that's driving it, use
XHTML and embed some RDF within it by namespacing.


You might find it useful to read up on the Semantic Web techniques,
for which I'd suggest Passin's "Explorer's Guide to the Semantic Web"
<http://www.amazon.com/exec/obidos/tg/detail/-/1932394206/codesmiths-20>