https:/.../xml_css_entities.mp4

Okay. I'm back, and the first part
of this lecture is gonna cover entities.

And then I'll break again, and cover
the CSS piece in a separate recording.

There's really two different
types of entities.

One of them you can use, general
entities, to lure data into XML documents,

and then you can use parameter
entity references, um...

to make data become part of the DTD.

For example, for general entity,

you would use them for common
strings of text that we'd like to

define in a single place,
and use it multiple times.

Some of those might be,
for example, a company name.

If you were to use the same
document to generate, say,

a report for different companies,

instead of trying to go in and edit
the company name for each company

that you generate the report from,
if you use a general entity,

you could define it in one place, and
then publish the report for one company,

and then go change the variable,
that text from one place

and print the report for
the second company.

So it lets you kind of, almost like a
variable, or in something like Frame,

or even Word has something like this.

So, you can use string substitutions.

Another example might be, say that
you're developing some documentation

for a software project, and the name of
the software might change if you,

a lot of times, the names of things when
you're working on software projects,

they are not always stable.

And you know that the product name might
change, or a menu item might change.

Instead of typing that menu item all
over the place, you could make an entity,

insert that entity in your documents,
and then if they do change the name,

you only have to change it
in the one place,

instead of all over all the different files.

The example uses of a parameter
entity would be, sometimes you have,

once you start building out all the DTDs
that you would need for a doc set,

there might be some information
that's used in multiple DTDs;

for example, addresses. You might
have addresses in several different

deliverables, or documents. And instead
of defining those elements for address

repeatedly in all of these different
DTDs, you could define those,

the elements that make up
an address, in one DTD,

and then make pointers to all those
other DTDs to that one location.

And it helps you single-source,

and not have to keep redefining
the will all the time,

or keep redefining the same
sort of structure all the time.

So, we'll go through that.

It's a little fuzzy right now, I'm sure,
from just a description.

But it's just ways to either re-use text
in an XML file, or to re-use the structure

that you defined in one DTD
in another DTD, instead of redefining it.

Walking through this example with, like,
the contact element that we've seen

in other lectures.

So here's an example of a general entity.

And you'll notice that
it's defined in your DTD.

And it has almost the same structure
as Element; it's a little bit different,

in that, instead of Element, it says Entity.

And then it has the name of the entity,

and then what you want
the substitution to be.

So for example, we're, in this example,
creating an entity called Company.

And in your XML file, you want
wherever you put the entity,

you want it to say "XYZ Software."

So how does this work in your XML instant?

If you remember back when
we talked about apostrophes,

and those special characters
that you can't type,

and you have to use those special
symbols for them, the ampersand,

the less-than, the greater than.

Those symbols?

It has the same structure.

If you remember back to the ampersand,
when you want to insert an ampersand

into your document, you had to do
the ampersand, AMP, semi-colon?

It's the same thing for if you define
your own entity reference.

So for example, how we defined it here
is ampersand, company. Semi-colon.

Sorry; I have to put the cursor here.

So it's there.

Ampersand company, semi-colon.

And here's another use of it. And you
can use it as many times as you want

in your file, and if you have multiple
files used in the same DTD,

you just use the ampersand-company-
semi-colon wherever you want,

as many times as you need to, and every
time that this document is transformed,

it will turn that ampersand-company-
semi-colon into "XYZ Software."

So for example, this is what
the output looks like now.

Where you saw the company,
ampersand company,

it's now saying XYZ Software.

XYZ Software. Let's go back and look
at previous page a moment again.

This is the customer list for &Company;
organization company.

And that's been transformed into
XYZ Software, XYZ Software.

Now, if you wanted to
go back into DTD now,

and change that entity reference
to say ABC Software,

then the value would also
change after you output it,

without you touching your XML instance.

XML instance still says
&Company;.

All you do is you change it in the
DTD, you re-run the transformation,

and suddenly, it has substituted
different text in there.

So it's really just a variable.

You can also use general entities to
include files within an XML instance.

So for example, here's a DTD...

For book. And it's...

You, within it, define three entities
for chapter one, two, and three.

And then, within your...

... book, where you want to include
chapters one, two, and three,

when you transform this document,
it's going to take the contents of

these XML files that you've defined here
as chapters one, two, and three XML.

When you publish this book, it's going
to insert them at those places within...

all your documents.

So this is very, very similar to what
you need to do for the recipes

in the cookbook. You're going to
have something very similar to this

at your cookbook file,
and it's going to

have some sort of title and
some sort of introduction;

and then you're going to insert

each of your recipes in order,
in the same fashion.

And you'll create an entity like this,
that will point to your recipes.

So for example, you might have
Entity Recipe 1, System.

Recipe 1.XML.

Entity Recipe 2 System,
Recipe2.XML.

So, these entities are going to
point to your XML files

for each of your recipes, and then you're
going to insert those entities here,

and then, when you transform
the document, it's going to take

the contents of each of your individual
recipes and add it back in...

to the document.

And so, that's a way, for example,
say that you were writing, uh...

—a software manual, and some chapters
might appear in like, multiple books.

Say that you have a user guide
and a reference guide,

and a getting-started guide that's
all talking about the same product.

If the... Chapter One is some sort of
overview that describes the software,

and you want it to be in
each of those books;

you would only have to define
that Chapter One once,

and then, include it... in the—

do it as a parameter reference;

I mean, as a general entity
reference—in each of those books.

So it's a way to be able to reuse files,
and once you get into DITA,

you're going to see that
DITA kinda does this a lot.

It's going to be a totally different
mechanism than DITA when we get there;

but it's kind of doing the same thing.

It's basically, you're making,
like a shell file.

That you're gonna run the
transform on, but that file can point

to different files; to additional files,
so that when you run it,

you get all the content of
all the files you're pointing at; um...

To make a single deliverable.

And we'll go through this
some more as we...

... work on this.

So here is, uh...

The other type of parameter
that we're talking about;

that would let us re-use DTD structures.

And in the, uh...

So for example, in this one.

What we're trying to reuse...

is this contact's name;
last name, first name.

So we have this specification
that we've done for contacts.

And then we find out that we wanna
use contact in a customer list...

A contact list of customers, as well
as in a contact list of employees.

Well, the contact information
is pretty much the same.

Some of the other information might
be different in each of these DTDs.

For example, over in this one,
we have a description;

we have the organization name
and the company name.

But each of these,
besides that information,

each of them wants to
have contact information.

So instead of defining it in both
the contact list for customers

and in the contact list for employees,
you can define in a separate file

the information for contacts.

And then within the
contact list for customers

and the contact list for employees,
you create an entity.

And the entity's going to point to
the DTD for contact simple.

So that when you're wanting to
create a contact list for customers,

you can have that very specific information
for customers in the introduction,

and then use the...

—the standard definition for contact,
and the same is true for employees.

You could have that generic
employee information in front,

and then point to the contact information
to get the structure of the contact.

And this lets you reuse your DTD
structures across multiple DTDs.

In both of the examples, the customer
list and the employee list contains

a series of contacts, but the other
elements in the DTDs are different.

Both DTDs can point to the contact DTD

to pull the structure
from the DTD document.

The parameter—

The syntax for doing this
is that you would say, "entity."

Percent sign. Contact.

System, to indicate that it's a file on your
system; and then the name of the file.

If you were going to do it this way,
because we don't have a path here,

that DTD would have to be in the
same folder as the other DTDs.

And then you would also need to say,
percent-sign, contact, semi-colon.

And this is the same structure that we
used [inaudible]

ampersand, and stuff like that, almost.

It's that same sort of structure.

The entity statement
only defines the entity.

So this line here, actually only defines
that this entity exists.

It doesn't actually get inserted until
you put the percent-sign, contact,

semi-colon. That actually uses it.

I usually put these things together
in a DTD, but you don't really have to.

You just have to make sure that
you define what the entity is

before you actually use it.

So this has to come, this line has to
come somewhere in the file

before you insert the percent-sign,
contact, semi-colon,

because otherwise, it would hit this
and the transform will break,

because it won't be able to find this.

Or the validation to the DTD will break
because it wouldn't be able to find it

because it hasn't been defined yet, so.

You have to define this verse,

and this line is actually
what uses it within the file.

When you are to go to use
the contact list for customers,

you wouldn't really notice, in the
authoring environment, a difference.

It would still have all of
the elements available;

same Oxygen in the elements window;

you really couldn't tell the difference
as you're creating the document.

The difference is all in the back end.

But the authoring experience is the same;
the contact element would be available

seamlessly into the contact list of
customers; they wouldn't notice

that this contact is actually
defined in a different DTD.

The person authoring really
doesn't care; it's all in the back end,

and it will let you put the
elements where they belong.

Also notice that the DTD—

I mean, the XML instance
only refers to that one DTD.

It only refers to the bigger one
that's pointing to the littler one;

or the shell DTD pointing to
the child DTD, so to speak.

So you wouldn't have a doc-type
statement for both of those files;

you would only have it for the one
that is including the other file.

'Cause it's sort of like the,
defining the overall structure

while the contact DTD is only
describing one small piece of it.

The DTD that pulls in another DTD
is sometimes called a shell DTD,

and you'll see this a lot in DITA;
they'll have—um.

And the reason they do this is, like—

We'll go into DITA a lot more in
the second half of the semester,

but DITA defines four different
types of topics at the base level.

There's concept, fast reference,

and then there's regular topic;
kind of a generic topic.

And the reason that they use parameter
entities is because there's these

low-level elements such as Paragraphs,
Notes, Lists, things like that;

that they only wanna define in one place.
All topics will include those elements.

All topics types will have
paragraphs in them,

and they'll have loose items in them,
and they'll have notes in them,

and things like that, but they
only wanna define it once.

So they create a DTD that defines
all those basic elements, um...

and then they'll create another DTD
that pulls those elements

from that common DTD into them.

So, they can define things one time;
all of the element structures;

all of the details of these
elements in one place,

and then they can reuse
them in multiple topics.

So that's really why we
kind of use these structures,

is just to be able to define
commonly used things in one place,

and use them across
all of the DTDs,

or all of the structures that
you need to use them.

And when we have a DTD like this,
where we're pulling in, basically,

the information from another DTD,
we sometimes call those a shell DTD.

Because what they are is they're
providing like, the infrastructure

or the shell in which all the
other details will be added.

And you'll see this when
you're thinking about your...

Recipes, in your cookbook.

The cookbook's going to be a shell DTD.

It's going to be pointing
to those other...

—the DTDs for recipes,
to pull in their structure.

So that's where this is gonna really apply
when you're working on your project,

and you'll see, hopefully,
how all that will work together.

And that's pretty much where, um...

we're going to end
this part of the lecture.

I wanna step back one more...

One more time...
to a previous slide.

And just really draw your attention
to this particular slide.

Because this is really, describing almost
exactly how you're going to put your

recipes together into the cookbook.

So, when you get to your cookbook,
your recipes in your cookbook,

you're going to create a DTD.

And you're going to, you know.
Add the three recipes to it.

And then you're also going to...

Uh, point, just like I'm pointing
to contact, right here.

I'm sorry.

Contact, here.

You're going to have
something for recipe like this,

where you're gonna have
your element recipe, and...

whatever pieces
make up your recipe.

You're gonna have a separate file,
a DTD file, just for your recipe;

and then you're going to have
some sort of file like this

contact list customers file
that's going to have—

Instead of contact list customer,
it's gonna be like your cookbook,

and it could have a title.
It might have a description.

And then it's going to, where this says
"Organization" and a plus sign,

you're probably gonna have something
that says "Recipes" and a plus sign.

And then here, uh...

You'll have something
that basically says...

Entity...

Percent sign.

Recipe system.
Recipe-dot... DTD?

And then you'll have
something here that would say...

Percent-sign, recipe, semi-colon.

And that would be, really, how you
would define that cookbook structure.

So, I'm going to close this
part of the lecture down now,

and record the final piece.

Okay, so the first part of
week five's lecture,

we're gonna do a very, very,
very brief introduction to CSS.

I know some people are familiar with CSS.

CSS just stands for Cascading Style Sheet,

and it's the way that you apply styles
to XML and HTML documents.

Without CSS, you can use HTML tags
to structure your document,

and the browser will format the
elements using default values.

So, the browser will make it
look like something.

But CSS allows you to provide
specific formatting properties

so that you can give your
document a unique look.

And here's an example.

This particular... it's the
HTML output for resume.

And it has no cascading style sheet.

It's just basically using
the default attributes;

the way that tags look by default
within an HTML browser.

This is like an H1 element,
and then these are paras,

and then there's like, a B tag for
bola to apply to Career Focus;

and then maybe another B tag
applied to Experience Summary,

and then a bullet list... Um...

But there's no extra
CSS added to this;

it's just out-of-the-box what it would
look like if you open an HTML, um...

file that's using HTML tags with no
cascading style sheets associated with it.

What the cascading style sheets does is
let you kind of redefine the appearance

of the default values for the elements,
and kind of make things look different.

This is better-looking;
this still isn't, um,

something a web designer
would be proud of,

but it's showing you at least there's
some basic CSS that you can apply,

and make something look a lot better
than it does with its default tags.

Let's go back and compare again.

Here's the default. Kind of generic;
using Times Roman.

You know. Gets the job done, but
it's not particularly attractive.

But once CSS is applied, you can
put a lot more details in it

and make it look a lot better.

There's two ways that you can add
the CSS to your XSL file.

I'm going to show you the way
that I don't recommend first,

so that it will make the one I do
recommend that much better.

You can actually, in your XSLT file,
just add the style statements,

and they belong right after the title.

And you can just build out your style,
and kinda specify the different styles

that you would like to apply
to this particular HTML file.

And so then when you ran the
transform in your HTML file,

it would actually insert
all these style statements,

and then when it's rendered in the browser,
the browser would apply these styles.

You have to make sure that you put it
in the right location, in your XSLT file.

Browsers tend to be very forgiving
and probably will try to still style it

if you put it in the wrong place,
but it wouldn't really be valid,

and you might get
unpredictable results.

So make sure that if you
were to do it this way,

that you would put it in the
proper place, right after title...

within the head section.

The other, better alternative is
instead of actually inserting the styles

inside your XSLT file, is that you put
the styles in another style sheet.

In another file.

And then just point to the file.

For example, here, the styles
have been defined in this file,

called Resume_style.css,

and you just create this link to it,

and so then when it's outputted through
the transformation rendition,

it will, in your resulting output, will
make a pointer to that CSS file.

And the advantage this has is,
say that you've got 100 XML files,

and you run the transform and turn
these 100 XML files into HTML files.

That you've inserted your styles
directly into the file.

And then you realize that you were
supposed to make something blue,

instead of red.

If you have the styles directly
inside your HTML files,

and wasn't pointing to an external file,

then you would have to
go fix the XSLT file,

and then run those 100 transforms again.

But if you were to externalize it and
have a CSS file that they just point to,

you have that single CSS file;
all 100 HTML files point to it.

Then you would only have to
make the change in the CSS file;

wouldn't have to re-run
those 100 transformations.

You'd only have to make
the change in one place.

And that's what you hear me talk
about all the time in this course,

is that what you're really trying to do
is to make single-source things

so that you don't have to do the
same work over and over again.

So by having your styles
in a separate file,

you enable it to be in one place
so that if you need to change it,

you can without regenerating the
transformation for those 100 files.

So, the takeaway from this is,
try to use...

This. Adding style to
external style sheet.

And that's true whether you're
developing HTML pages directly,

or using XML and transforming
them to HTML.

It's really just a best practice to
always try to externalize your styles

and have them in a separate file
so that you can change them easily

and have that apply across the board.

We're going to kinda go through
now the syntax of CSS rule.

It will kind of remind you
of the XSLT rules, actually.

But it's formatted
a little bit differently.

Basically, a CSS rule
will have a selector,

and then the declaration. So for example,
in this one, the body is the element.

We're telling it what we
want the style applied to.

And then the declaration is
what styles are being applied.

And declarations are always
included in the curly braces.

There will be a name of the property
at the attribute that you're changing.

In this case, it's font family.

If you have more than one,
they're separated by a semi-colon.

The property is separated
from the value by a colon.

If you wanted to, you could
have these on separate lines.

You could have font family, colon,
arial, one line, hit return, and put

font-dash-size, semi-colon, 20px.

I mean: font-hyphen-size, colon, 20px,
semi-colon, on the next line down.

So you can have them on
separate lines if you want,

but you always do need to have
the semi-colon at the end.

Even if you only have one property here,

you still need to put the semi-colon.

You just always need that.

Here's a few of the common properties
that you might wanna specify.

Font-family is the type of font
you wanna use; it could be Arial,

it could be Times Roman; it's whatever
the font that you want to use.

Font-style, actually, is whether
you want an element to be...

italic, oblique, or normal.
It's basically making italics.

Font-size specifies the size
of the font, and if you look...

The "px" here stands for pixels.

So, this is a 20-pixel font.
So it's just the—

Pretty much the same thing
that you would see in Word,

where you're taking a font size
to make things bigger and smaller.

If you wanted the font size to be bigger
than 20 pixels, you would make it 24;

you know, 32, or... or something
like that. You could make it smaller.

So that's what font-size does.

Font-weight is basically whether
you want it bold or not.

List-style specifies the
styles for lists, margins.

Lets you put margins around an element,

or you can also use padding instead,
that's based around an element.

And then text-align is another one
that might be commonly used...

to specify the alignment of
the text on the right or left.

And this link. Uh, I'm not sure that
it's going to show it when I go there.

No, it's not. So, let me re-share
my desktop in a different way.

Give me a moment to try to
catch up. I thought I shared it.

There we go.

W3Schools has a reference section
on CSS, and the link's in there.

And it's going to tell you...

all of the different properties
in this reference section.

So for example. Now I'm scrolling
fast, but I'll let it catch up.

So for example, if you
go to the font section.

There's all sorts of different
font values that you can specify,

and you can come here and
see the different values for like,

font-size, -family, -stretch, -style.
You know, and this reference is a good

beginning reference to get your
head around HTML and CSS.

So you can come here and kinda
see what the different values;

like if you wanted to play with font-weight,
you could click on font-weight,

and it's going to tell you what values
you can enter, and you also will see...

This Try It Yourself button.

And when you click it on Try It Yourself.

It opens up this window that has
two different sub-windows in it,

and you can play with the
values here, on W3Schools,

to see what the different
things might do.

So, you know, they are basically...

putting out different values, and you can
come up here, and you could change...

the values, and see what effect it has
in this other window by submitting code.

And this is just a great way to kinda
test the different values and see

what results you might get.

So, I highly recommend
coming out and playing with

the different CSS values at w3Schools,
and kind of going through these

Try It Yourself buttons, and kind of
playing with the text,

and seeing what different
effects you might get from

changing different
properties different ways.

For your homework, you really don't
have to do a lot of CSS work.

As long as your output is presentable
and isn't all jumbled into a big mess,

I'm not gonna require for you to actually
do a lot of Cascading Style Sheets work

if you don't want to, but if
you want to actually...

It's just very important
to understand CSS

if you're going to do
any online work at all,

so I do highly recommend; and there's
other classes that really focus on CSS.

There's one that you can take in the
Technical & Business Communications

Department called "XHTML in CSS."

And then there's also, in the Visual
Communications department,

several classes on web design.
And I think it's just, uh...

Something that I would highly
recommend that you look into.

I can't cover it a lot in this class,
'cause we just have simply

too much to do with just getting the
basics of XML down.

But it's really, uh.

Is—Are skills that you really need to do

if you wanna go into a career
of technical writing;

is to understand how
Cascading Style Sheets work,

and how styles are defined,
and how to apply styles.

So I highly recommend that, and
also to take classes in web design,

and HTML and CSS class.

I think they're actually required
for the degree, I think?

I won't guarantee that,
because things changed.

But if not now [chuckles],
do study CSS in the future,

because you absolutely
will need to know that,

if you're going to work on anything
online. And a lot of documentation,

and a lot of technical writing is actually
being delivered online these days, so.

Highly recommend coming out here
and playing with the CSS tutorial...

at the W3Schools, and also make sure
that you take additional classes

in that, if you haven't already.

And I'm going back to our...

Selectors can also use classes to identify
elements upon which to apply styles.

Classes allow the style based
on an assigned class name

instead of an HTML element name.

And this is important for like, if you
wanted a paragraph in an address,

for example, to be formatted different
than a paragraph in a heading,

or below a heading, or a description,
or something like that.

You can assign class statements so that...

You can specify that a
paragraph in one context

looks different than a
paragraph in another context.

And the syntax for using a CSS class
is putting the element name,

a period, then the class name,

and then the property, the semi-colon,
the value, and the semi-colon.

So for example, if you wanted,

for the P tags, paragraphs.

With the class of zip code, you could
set font-size, semi-colon, 12 pixels...

Semi-colon. And then that would only...

When the transform's happening,
the browser actually...

this is when the browser's reading
the file, so it's in your HTML file.

You could have <p class="address">,
and that would be formatted differently

than <p class="school">, because
you have these styled differently.

P-dot-address has a margin of zero
points, and text alignment center,

while p-dot school—period-school—
has a font-weight of bold.

So you just add this—it's an attribute.

We've all seen attributes before,
but the attribute name is class,

and then you make up
a name for this part of it.

You know, address, school; it could
be Fred. I mean, it doesn't matter.

But in your style section, you
have to have the element name,

period, and the class name,

and then you can specify styles that
are specific for that combination.

In your XSLT, you would just do that
by when you're defining your values,

and you know, you're building
out your HTML formatting;

you can just add the class statements...

Oops. Sorry.

You could just add the class
statements to the paragraphs...

as you're defining out your XSLT.

And then when the transform happens, it
will insert those into your HTML output,

and then when you look at
the page in a browser,

it will format the page
using those class values.

And this demo is just a really
basic overview of CSS,

so that you can begin to apply a few
styles to your resume. Like I said,

I'm not going to really grade you on any
sort of elaborate CSS work in your file;

I really want you to focus on getting
your XML output into valid HTML output;

but if you want to really extend those
skills, you need to start looking at CSS.

And like I said, it won't affect your
grade, really, for this class too much;

and I hope this site's still here.

Uh, let's see; can I share that?

Okay, I wanted to share this website,
and let's see if I can.

There's a website called
www.csszengarden.com.

And what that website does—and I'll
try to share back over there.

And I'm sorry; I know things
start getting kinda...

Not as attractive,
and laggy, when I, uh...

Attempt to share things
outside of the browser,

but let's see if I can get this to work.

And what the Zen Garden website is

is it's a website that takes
the same basic HTML,

and it applies different styles to it
to show you what you can do,

just using different style sheets.
Same HTML underneath;

it's the same structure and
all the same HTML tags,

but it can look completely different
depending on the CSS that you apply to it.

So, for example...

Here's one design.

It's the same HTML file underneath;

what they've done is they've
created a style sheet for it;

and that style sheet has a very
specific look and design to it.

And I will stop there, so...

You can see a little bit of
what this page looks like.

And then, you know, we could pick
another design for the same text.

Same HTML file.

And it will have a
completely different look.

And it's all done through the
power of cascading style sheets,

and just formatting them different
depending on the different contacts.

So, I love this website just
because it lets you download

the HTML and the CSS codes so you can
kinda see what the differences are.

You don't have to, of course,
do that for this class or anything,

but I just—a teacher a long time showed
this to me, and I keep using it as an

example to show you, really, the power
of CSS and Cascading Style Sheets.

So, uh.

If you have a chance; and not a high
priority, but that website's pretty cool.

It'll really kinda highlight everything
that you can do with CSS, so.

I'm going to stop the lecture here.

If you have any questions, please
post them in the discussion board,

and uh... I will record
another lecture next week.

And remember, my office hours are
Wednesday night from 8 to 10 PM,

and on Saturday morning
from 10 to noon.

So, I'll talk to y'all later.
Thank you for listening.