With "Elements," our tour descending the primarily hierarchical arrangement of all the objects that constitute the website effectively comes to its logical conclusion. Elements are the lowest level container. They are the smallest, most granular system artifact which, by means of code or markup, can be controlled by the site developer: selection, placement, styling, behaviors, etc. All that remains after Elements is the actual content of those Elements, namely the final character text (#PCDATA) content. This text content is regarded as immutable, itself. This is by design, of course, supporting the goal of keeping content quite separate from presentation. The presentation of this text content is made possible and controlled only through higher level mechanisms (all the other website objects we have been discussing).
Having established that "Elements are the containers for the text content," it must now be pointed out that not all Elements necessarily contain text content directly. Only the inner-most nested Elements hold the text. In fact, Elements are the building blocks used to create the overall "content model" for a Document Type (DTD), which is often (almost always) a hierarchical set of nested Element containers of at least some little complexity. Some of these Elements may have the role of containing further, nested Elements only (no character text (#PCDATA)). Others, as noted above, may contain the character text directly (and character text (#PCDATA) only—no nested Elements). The third case is an Element that may be designed to allow what is known as mixed content (both #PCDATA and nested Elements, which are "sibling" to the text content).
These three kinds of usages for Elements are basic to the rules of XML and markup languages (beginning from SGML).
![[Tip]](images/tip.png) | Tip |
|---|---|
This might be the place to note another important concept from markup languages that is hardly used at all within this system, for the proprietary tags: the attribute (e.g. the 'src' in <img src="images/mypic.gif" />). The HTML elements of course have many attributes, but the proprietary elements tend to not use them (there's nothing to say you couldn't; it just hasn't been done in practice). | |
The key distinction for this website build system isn't so much whether the Element object holds text, other Elements, or a mix of the two, but instead the consideration of what in this system is called whether the Element is "Place-able" or not.
This concept is central to the use of the "Element-Zone Assignment" (EZA) mechanism (described next), which permits the site developer to re-design with ease the arrangement and presentation of the parts of content that make up a Module. (These "parts," not surprisingly, are the "Place-able Elements.")
The basic idea is to determine, within the set of tags in the BusinessML markup for a given Content Type, which Elements are significant enough to warrant "promotion," as it were, to being addressable objects from the point of view of the next level up on the hierarchy. That is, from the point of view of Module Type layout.
Addressable Objects. This is to say, all Elements are "addressable" objects, in the straightforward "local" sense you might call it, of within their Document. By virtue of being Elements, they represent named nodes that can be selected by name, by relationship, by position, etc., using XSLT, XPath, etc. This is in the inherent nature of Elements. But the EZA mechanism, and the concept of the "Place-able" Elements means that a certain number of Elements are selected as "Place-able," meaning you can record the Zone and Position in which they are to appear in the Module Layout presentation. This is the distinction of "promoting" these Elements to being addressable (and thereby "place-able") in a higher level arena: the Module Layout.
Keeping Presentation Separate from Content (again). What is the significance of this? The answer is best addressed by putting the question, "If we didn't have this mechanism, what would we have?" How would the <date> element from the BusinessML, for example, get into the top position in the uppermost <td> in the Module Layout <table>? The answer is that the Module Layout information would have to be implemented (the <table>) right into the BusinessML, and inside that first <td> would go the <date>. With this arrangement, the separation of styling presentation might be able to be kept from the content (via CSS), but the layout/positioning presentation choice is not separate, in the scenario described here.
The goal in authoring BusinessML content is to simply "follow the flow," that is, to author the blocks of content—the paragraphs and lists, etc.—straight down, block upon block. This is known as the "Flow" in W3C HTML and in page markup generally. No structures (e.g. <table>s) are used to position these blocks. The "Flow" doesn't concern itself with eventual, richer page or module layout considerations (multi-columns; colspans; etc.) used to present the content blocks. Presentational layout considerations are kept separate, as they may well may vary from one publication (website, etc.) to another, or from one version of a publication (website) to another (different look in fall than spring).
![[Note]](images/note.png) | Note |
|---|---|
The (eventual) widespread adoption of what was sometimes referred to as "CSS-P" (Positioning) may be a big help in separating out this positional information from the content. As current browser support for CSS2 (incorporates CSS-P) remains decidely uneven, (particularly for certain aspects of combining relative and absolute positioning), the continued use of the <table> and <td> cell will be with us for a while. | |
The EZA mechanism permits the avoidance of using any <table> markup in the BusinessML to represent presentational information (you may use <table> for truly tabular information). This flexibility permits the same BusinessML content to be applied to different Module Layouts with ease.
There isn't a great deal more to add concerning "Non-Place-able Elements." Perhaps the key idea to note is that they are regular Elements in the straightforward sense (as in the regular XML specification sense). What's particular for this website build system is that they are by definition a child (a descendant, more precisely) of a Place-able Element.
Non-Place-able Elements cannot be assigned Zone and Position placement, nor can they be singly selected for display or suppressed from display. Each "Non-Place-able" Element will by definition have an "ancestor" (parent or grand-parent, etc.) element that is Place-able, and it will be the selection and location of that ancestor Element's placement that will of course determine where (and whether) the Non-Place-able element will appear.
| Note |
|---|---|
The "type" of Element discussed above (regarding #PCDATA, etc.) is not relevant to this question of being Place-able or not. Every Element, Place-able or not, may hold either:
| |