[This local archive copy mirrored from the canonical site: http://www.4thworldtele.com/public/design/rsdesign.html, text only; links may not have complete integrity, so use the canonical document at this URL if possible.]
4/16/98
4thWORLD Telecom
The real estate DTD(s) needs to work with several different user types; those
making MLS entries using custom software (such as OpenMLS), those making MLS entries
with standard XML editors, and those who are simply making a web site (separate from
MLS entry). With these scenarios, the DTD must balance the detail needed in
the MLS with the simplicity that web developers desire. In addition, there are no
MLS form guidelines given by the NAR (although they may currently be working on some).
Therefore a very general purpose MLS form must be distilled from the customized documents
that the various Board of Realtors will produce with this DTD. [Please see "MLS
Handbook" published by the NAR]
|
<!-- Parameter Entities --> <!-- Notation Declarations --> <!ELEMENT RESIDENTIAL-LISTING (GENERAL,FEATURES,FINANCIAL,REMARKS,CONTACTS)
> <!-- -------------------------------------------------------------------------
--> <!ELEMENT MLS-CODE (#PCDATA) > <!ELEMENT TYPE (#PCDATA) > <!ELEMENT PRICE (#PCDATA) > <!ELEMENT AGE (#PCDATA) > <!ELEMENT LOCATION (%ACZ;,ROUGH?) > <!ELEMENT ROUGH (#PCDATA) > <!ELEMENT STRUCTURE ((NUM-BEDS|NUM-BATHS|BUILDING-AREA|ADD-INFO)*) > <!ELEMENT NUM-BEDS (#PCDATA) > <!ELEMENT NUM-BATHS (#PCDATA) > <!ELEMENT BUILDING-AREA (#PCDATA) > <!ELEMENT ADD-INFO (#PCDATA) > <!ELEMENT DATE (#PCDATA) > <!ELEMENT LAND-AREA (#PCDATA) > <!ELEMENT STATUS (#PCDATA) > <!ELEMENT TERMS (#PCDATA) > <!-- -------------------------------------------------------------------------
--> <!ELEMENT UTILITIES (#PCDATA) > <!ELEMENT EXTRAS (#PCDATA) > <!ELEMENT CONSTRUCTION (#PCDATA) > <!ELEMENT ACCESS (#PCDATA) > <!-- -------------------------------------------------------------------------
--> <!ELEMENT ASSUMABLE (#PCDATA) > <!ELEMENT OWNER-CARRY (#PCDATA) > <!ELEMENT ASSESMENTS (#PCDATA) > <!ELEMENT DUES (#PCDATA) > <!ELEMENT TAXES (#PCDATA) > <!ELEMENT LENDER (#PCDATA) > <!ELEMENT EARNEST (#PCDATA) > <!ELEMENT DIRECTIONS (#PCDATA) > <!-- -------------------------------------------------------------------------
--> <!-- -------------------------------------------------------------------------
--> <!ELEMENT COMPANY (%NAME;,%ACZ;,%PFW;) > <!ELEMENT AGENT (%NAME;,%ACZ;,%PFW;) > <!ELEMENT OWNER (%NAME;,%ACZ;,%PFW;) > <!ELEMENT TENANT (%NAME;,%ACZ;,%PFW;) > <!ELEMENT COMMISSION (#PCDATA) > <!ELEMENT OTHER (#PCDATA) > <!ELEMENT NAME (#PCDATA) > <!ELEMENT ADDRESS (#PCDATA) > <!ELEMENT CITY (#PCDATA) > <!ELEMENT ZIP (#PCDATA) > <!ELEMENT PHONE (#PCDATA) > <!ELEMENT FAX (#PCDATA) > <!ELEMENT WEB (#PCDATA) > <!ENTITY lt "<"> |
There will be a separate DTD for each of the major property categories; commercial,
residential, vacant-land, working-land. Each of these DTDs will be divided into four
or five major sections. For example, the commercial DTD has GENERAL, FEATURES, FINANCIAL,
REMARKS, CONTACTS as the major sections. In this case, GENERAL is used for the general
information such as location, price and size. Security is a big issue and is describe
in greater detail below. Essentially, the agent can give security attributes to any
tag, thereby defining what can be used in a public web site. The REMARKS section
is where an agent can write a free form description of the property and should appear
in every DTD category. In a typical web site application of the document, the REMARKS
contents could by displayed next to any images of the property followed by any public
MLS information.
It is very important that the given tags be used for their intended content. For many of the tags, it is clear what sort of information the should contain. the PRICE element clearly contains the price for the property. What might not be clear is that it should only contain the price number and not even the monetary sign ($). Some of the tags may be open to confusion due to their brevity. The following should help.
The following should contain numbers and nothing else. Strong typing (integer, float, etc.) is not in the current XML specification, but workarounds via namespaces and XML-Data should help to type certain elements. The following are out of the RESIDENTIAL DTD. Other DTDs have slightly different element names, but the idea is the same. Although other elements may contain only numbers, such as DUES, the following are critical for they will be searched on as a major criteria for properties.
Users should be able to change the title and this would appear as an attribute
in the element tag. Most of the tag names are very short and generic. Many Boards
of Realtors will want to modify them in their MLS entry. This information should
appear in the resulting MLS document. There may be multiple items in a tag. Each
item should be separated by a character that clearly indicates that these are separate
items. As an example I have used a semi-colon as this seems more effective than a
comma.
|
<FEATURES> <DISCLOSURES TITLE="Special Disclosures">
<ACCESS TITLE="Security"> </FEATURES> |
Since there is no standardized MLS, each Board of Realtors develops their own to fit the needs of their geographical area. It is therefore necessary to provide these boards with the ability to customize their input. This is OpenMLS's plan and it makes sense that other MLS software programs that use this DTD will do the same. We cannot allow the creation of custom XML tags as this will create invalid documents (that do not match the DTD). It seems that the solution is to allow the users to create custom database "fields" that are contained within a particular tag. These are not fields in a strict DB sense, but simply general headings and their contents. These entries should have a standard way of separating a custom field from its contents as well as a standard way of separating multiple custom fields contained within a tag. The separators should make sense so that in their rawest format, an unfamiliar human reader could make sense of the information. In the example below, the fields and their contents are separated by an ellipsis. Multiple fields are separated by semicolons and carriage returns. At first glance you may feel that field and contents should be separated by a colon. However, Namespaces may use colons in a very similar manner and it may be confusing to the human reader.
NOTE: the OTHER tag is the catch-all tag. It appears in all major sections and in all DTDs. Also, in the interest of clarity, not all of the attributes that might be used with these tags are given in the examples below. Also note that tags can have a null content value or none. Thus tags can appear as necessary in the DTD but as an option be filled with "n/a" or "none."
| <FEATURES> <OTHER TITLE="Special Features"> Shipping Doors...3 ; Energy Rating...5 Star ; Substructure...Below Grade Basement; Substructure...Slab; </OTHER> <CONSTRUCTION TITLE="Construction Materials"> Roof...Metal ; Walls...Rock ; Floors...Wood ; </CONSTRUCTION> </FEATURES> |
|
Shipping Doors...3 Energy Rating....5 Star Substructure.....Below Grade Basement Slab Construction Materials |
Security is a critical issue. Because of the multiple use nature of the real estate DTDs, some information will be restricted MLS information for Realtors only, while everything else can be used in public listings. So, certain elements have security levels (MLS-Only, Restricted, and Public). The "Restricted" attribute is reserved for additional differentiation if necessary. Larger companies may have two internal levels of security. Either way "Restricted" is reserved, but not for public consumption. Although there are default settings for the security levels, they can all be set by the inputting agent.
| <FINANCIAL> <ASSESMENTS SECURITY="MLS-Only"> Yes </ASSESMENTS> <DUES SECURITY-LEVEL="Public" TITLE="Monthly Home Owner Dues"> 125 </DUES> </FINANCIAL> |
Yet to be determined is whether the MLS information will be indexed by a third
party commercial search service (I hope this is the case as it is best for those
involved). Local boards may get touchy and paranoid and keep the information all
to themselves, which would create dual and uncoordinated databases, one MLS for Realtors
and one public index for general listings.
The following sections describe the worst case scenario
in which two separate documents are made and indexed, the full MLS version and the
public version derived from it.
Following figure 1, the inputting real estate agent would first bring up the MLS software on their office computer system. The software would guide their input and the finished document would be saved locally. A copy of the document would be given to web site developers. Two identical web sites would be created with the difference that one would be for Realtors with full MLS information. The other would be for public consumption. Both of these documents would be put onto the ISP web server. Both documents would then be spidered and indexed by a commercial search engine.
Following figure 2, the inputting real estate agent would first bring up the MLS software on their office computer system. The software would guide their input and the finished document would be saved locally. A copy of the document would then be placed in a server outside the firewall for spidering and indexing by a commercial service. The resulting indexed file would only produce a very basic looking form of information, but sufficient for MLS purposes.
A web developer would be able to use standard XML editors (and XSL or CSS) to
create a web site. Although there is a great deal of information that may not be
needed in a simple site, any XML editor would guide the user according to the document
context in which they were writing and editing. The remarks section would be where
the free from "flowery" description of the property would be written. In
my opinion, the remarks section would be the lead-in for the property followed by
the general description, features, and contacts.
Certain aspects such as automated
search attributes, strong typing, namespaces etc. have been left out of the example
DTD given. They will be included in future versions.