CS 328 - Week 15 Lecture 1 - 2025-05-05
TODAY WE WILL
* announcements
* WHIRLWIND TOUR intro to XML and JSON
* prep for next class
=====
* should be reading/working through zyBooks Chapter 7 - 7.1, 7.7, 7.8, 7.9
* talking about some of this now!
* deadline for credit for its activities: 11:59 pm Friday, May 9
* Homework 11 IS the last homework;
* improved versions of problems from Homeworks 10 and 11 must be
submitted by 11:59 pm on SATURDAY, MAY 10
* WATCH for class e-mail when
homework-small-extra-credit JavaScript problem
is posted, to be due by 11:59 pm on FRIDAY, MAY 9
************
intro to XML and JSON
************
* XML - eXtensible Markup Language
JSON - JavaScript Object Notation
* XML and JSON are really just two text-based notations for:
* representing data,
* stucturing data,
* passing it back and forth between applications;
...being text-based, they are lovely and portable!
...being standards, applications and DBMSs can agree
to output and input data in these notations
to make it easier to transfer data back and forth...!
* (and BOTH are used for such in both web
applications AND other applications as well)
* both are structured enough --
and have strict-enough syntax --
that it is quite reasonable to parse them as desired;
BUT! both are widely-used enough
that there are quite a few LIBRARIES
out there so you don't necessarily HAVE
to write your own code to parse them;
* (for example, PHP has libraries for both!)
=====
first: more on XML
=====
* again: eXtensible Markup Language
* a W3C thing!
* designed to DESCRIBE data,
and focus on WHAT data is;
* it IS a markup language, using a strict-style-HTML type of syntax --
it DOES use tags in angle brackets!
...you could argue it is really a META-language, that lets
individuals or groups specify/create customized markup languages;
* and also provides a way to specify rules for
those languages;
* XML tags are NOT predefined --
you define your own, but following this strict, specific syntax
* and you can formalize the rules for your resulting markup
language for your desired domain by defining
either an XML SCHEMA or a DOCUMENT TYPE DEFINITION (DTD)
* (these are two different ways of expressing such
rules,
* and both provide a way to VALIDATE data that is
supposedly written using the resulting rules)
* that is, when a group/organization/individual etc. wants to
formalize a set of elements and rules for describing a
certain kind of data,
they can formalize those in a DTD (Document Type Definition)
and/or an XML Schema to describe that type of data,
* and then applications can use those to verify XML using those
formats
=====
a little XML terminology
=====
* XML with correct syntax is called: *well-formed* XML
XML validated against a
DTD or XML schema is called: *valid* XML
* a well-formed XML must follow a standard structure:
^^^^^^^^^^^
vvvvvvvvvvvv
* starts with an XML prologue, which includes an XML declaration
and (if applicable) which DTD or XML Schema is being followed
* example of an XML declaration:
<?xml version="1.0" encoding="ISO-8859-1" ?>
* example of a DTD declaration/doctype:
<!DOCTYPE html PUBLC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
* after the XML prologue you need a root element!
* a root element contains all of the other elements
(like the html element is the root element for an HTML document...)
* that is, all of the document's content is within that
root element
* XML's syntax SHOULD hopefully sound familiar since you've been
writing strict-style HTML this semester:
* an element is defined as everything from its start tag <blah> to
its end tag </blah>, including everything in-between
* and an element's content is everything between its start
and end tags (*not* including the start and end tags)
* Every element must have a start tag and an end tag.
...elements that can never have content (void elements)
must be written as:
<blah />
* (so they are written as both start and end tags)
* comment: <!-- comment -->
* Start tag and end tag element names must match;
* and case matters in element names in start and end tags
(they are case-sensitive)
* Start tags can contain attributes,
but each attribute must have a value,
and that attribute value must be quoted
(single or double quotes are fine)
* elements must be properly nested
* elements are related as parents and children
* the root element is parent for other elements in the document
(and maybe grandparent, great-grandparent, etc.)
* it is an ancestor for all of the other elements in the
document
* an element B within another element A can be called a child element
of element A
(and element B might itself contain children elements,
and those would be grandchildren of element A,
etc. -- can have levels of descendants)
* elements can have different kinds of content:
* element content - an element contains one or more
other elements (and that's it)
* this element, moo, has element content:
<moo><baa> Wool </baa></moo>
* in xml-ex1.xml, root element note has element content
* simple content - has JUST text content
* here:
<moo><baa> Wool </baa></moo>
...element baa has simple content
* in xml-ex1.xml, elements date, to, from, heading, and body
all have simple content
* mixed content - an element contains both element and simple
content
* here:
<poster> Upcoming Event
<bullet> Date </bullet>
<bullet> Time </bullet>
</poster>
...element poster has mixed content
* in my-first-xml-book.xml, both instances of the chapter
element have mixed content
* empty content - an element has no content
* I *believe* (based on W3Schools) BOTH of these are considered to
have empty content:
<sound />
<aroma></aroma>
* in xml-ex1.xml, element widget has empty content, and
in my-first-xml-book.xml, element prod has empty content
(remembering that attributes are NOT content)
* and NOTE: if an element has attributes, those are NOT
considered content! <-- content is between start and and tags!
* see some examples of XML (adapted from several sources) in the posted:
* xml-ex1.xml
* xml-ex2.xml
* my-first-xml-book.xml
* xml-messages.xml
=====
JSON - JavaScript Object Notation
=====
* another text-based notation for structuring data,
BASED on JavaScript's object syntax;
it is BASED on JavaScript's object syntax,
but is NOT identical to it!!!
* JavaScript developer Douglas Crockford says he "discovered"
it (rather than calling himself its inventor!)
for exchanging data conveniently
* yes, JavaScript works very well with it!
* BUT other languages often include tools for
dealing with it, as well
* useful approach: consider JavaScript object syntax,
then compare it to JSON:
=====
JavaScript object *syntax*
=====
* JavaScript uses a prototype object model
...you can just create an object!
* (you don't have to create a class first)
* object literal syntax:
write a set of comma-separated data field/value pairs
inside curly braces:
{
datafieldname1: value1,
datafieldname2: value2,
...
datafieldnameN: valueN
}
* want a method?
...make the datafieldname's value a function!
* want an array data field?
...make the value an array!
...and that's a JavaScript object literal!
* it can be assigned to a variable, it can be passed
to a function, etc.!
* if you assign an object literal to a variable,
you can access its data fields using the familiar dot notation
my_object.datafieldname
* although you can ALSO use associative-array syntax as well,
treating the data field name like an associate-array key!
my_object["fieldname"]
* see example posted along with these notes:
* js-object.js
and also:
* js-object-demo.php
...that demos some JavaScript expressions
using this example JavaScript object's data fields
=====
JSON syntax
=====
* BASED on JavaScript object notation,
WITH some differences!
* you HAVE to put the JSON data field names in DOUBLE-QUOTES
* (we saw, in js-object.js's object literal example,
that this is NOT the case for a JavaScript object!)
* a JSON data field may NOT have a function as its value
* a JSON data field CAN have as its value:
* numeric data,
* string data,
* array data, or
* JSON data, though!
* a FEW character are forbidden on JSON for compatibility reasons
* a *cursory* Google search implies maybe they just have to be
escaped, though... like a double-quote or a backspace...?
* I did find that a \ within a JSON data field's string
"broke" an example JSON object, but replacing it with \\ seemed
to be fine.
* you cannot have comments in JSON...!
* CAN kluge by putting them in a data field!!!
* Many languages can handle JSON data --
JavaScript is definitely one of those!
* https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON
notes the following about JavaScript's object JSON:
"The JSON namespace object contains static methods for
parsing values from and converting values to
JavaScript Object Notation (JSON)."
* you can transform a JSON string into a JavaScript object using
the JSON object's parse method:
let myObjVersion = JSON.parse(myJSONString);
* and you can convert a JavaScript object into a JSON string version
using the JSON object's stringify method:
let myJSONVersion = JSON.stringify(myJavaScriptObject);
* note: looking at js-object-demo.php's last alert pop-up
when it is run, it *looks* like JSON.stringify() may simply OMIT
methods/data fields with function values;
* see some examples of JSON (adapted from "Web Programming Step by Step", 2nd edition,
by Stepp, Miller, and Kirst):
* json-response-data.json
* json-books.json
* json-messages.json
=====
* also now posted after class:
* simplexml-demo1.php: demos PHP SimpleXML package
* php-json-demo.php: demos PHP JSON extension
* you will practice lightly with these in Friday's lab exercise