|
Data Consortium Standard Practice |
©2001 All Rights Reserved. Distribution policies are governed by the Data Consortium intellectual property terms.
The Named Value Notation is a semantically-oriented convention for tagging information within xhtml and other xml files. It builds on W3C standards, primarily xml Namespaces, XPATH, and RDF and RDF Schema; it does not extend these xml dialects. The conventions do extend the European Computer Manufacturer Association standard for scripting languages (for example, Javascript), but only in the manner that numeric indexes are handled.
By following the standard practice defined here, all document exchange intended to conform with Data Consortium standards is now exclusively based on the xhtml protocol for physical transport. Although this standard practice specifically accommodates exchanges of documents encoded with non-presentation oriented xml dialects, such exchanges are not recommended for the reasons given below as suitable for standardization by the Data Consortium.
This standard practice is an outgrowth from the development of an RDF Schema-based dictionary of nouns, verbs, and qualifiers used in the commercial real estate sector. As such, the technical design of the dictionary is involved with the description of the technologies used to represent business object models created in support of this industry. An earlier publication -- the Data Consortium Namespace, Document Type Definition Version 1.50, is being re-issued as a physical xml schema associated specifically and only with the Data Consortium's Toolkit of CORBA objects.
This document is a proposed standard for consideration by the membership of the Data Consortium.
Please send comments to John McClure jmcclure@hypergrove.com or to the publicly archived distribution list at http://groups.yahoo.com/group/DCNArchitecture/join or at the Data Consortium Website's Bulletin Board.
To facilitate early and easy adoption of standards for xml documents exchanged among Data Consortium members, an approach is adopted that builds upon existing methods, processes, and tools being used today by web applications developers . Today, the building of Dynamic html forms and documents is central to applications development, a fact expected to remain generally true for the near-term future. Given this existing environment, a standard whose success is predicated on a sudden adoption and mastery of new technologies, is one that is likely adopted only after a difficult transition period for all organizations involved, during which the enthusiasm for standards may flag, or even the standard itself may become obsolesced.
Identifying a set of conventions rooted in today's well-understood technologies — conventions which meet our fundamental requirement to extract data from files received from another Consortium member — is the goal achieved by this document. Previously, a Document Type Definition (DTD) for commercial real estate documents was specified, despite the implicit consequence that, in order to participate in standard exchange, an organization needed to learn and adopt new tools specific to the Data Consortium's own, custom, DTD. In practice, this has resulted in significant pushback by Data Consortium members already engaged in creating their own, in-house DTD; by members unwilling to invest in new xml tools or xml training for staff; and by members expecting other (larger) standards efforts by related vertical industries and by horizontal quasi-government consortia to overwhelm the (smaller) standards effort initiated by the Data Consortium.
In light of this, it was imperative to review our development process for "xml standards" with a focus on leveraging members' investment in today's html-based technologies. Creating xml standards in an html world may appear in conflict, however the Hypertext Markup Language has been xml-ified as "xhtml" by the W3C. This means an xhtml file is an xml file; exchanging xhtml files is exchanging xml files; and defining standards for the coding of xhtml is establishing xml standards. Confusing may be that xhtml is still referenced as plain, old "html", when in fact xhtml is backwards-compatible with html browsers. This document, for instance, is in a file whose extension is ".html" even though, internally, it is an xml file, encoded using the Extensible HyperText Markup Language (xhtml).
This document gives a systematic, compact and informal description for the construction of names that can be assigned to textual values within xml files. These names are encoded as the value of an xml namespace-qualified names attribute that has global application, that is, it is an attribute that can be placed onto any xml element. For instance, assuming an xml namespace qualifier dc: has been defined, then the following codings are legal within a well-formed xml file.
<span dc:names='Facility.Name.text'>The White House</span>
<span dc:names='Facility.Resident.Name.text'>John Adams</span>
<span dc:names='Facility.Address.AddressLine.text'>1600 Pennsylvania Avenue</span>
<span dc:names='Facility.Address.PostalCity.Name.text'>Washington</span>
<span dc:names='Facility.Address.PostalDistrict.Name.text'>District of Columbia</span>
<span dc:names='Facility.Address.PostalCode.text'>10001</span>
These names for text content of span elements have tokens which mimic an arrangement of similarly-named elements in a typical xml file.
In effect, a name is an XPATH expression that would be used to retrieve the same information from a structured xml file, albeit a "period" rather than a solidus (/)
separates the tokens.
<Facility>
<Name><text>The White House</text></Name>
<Resident>
<Name><text>John Adams</text></Name>
</Resident>
<Address>
<AddressLine><text>1600 Pennsylvania Avenue</text></AddressLine>
<PostalCity><Name><text>Washington</text></Name></PostalCity>
<PostalDistrict><Name><text>District of Columbia</text></Name></PostalDistrict>
<PostalCode><text>10001</text></PostalCode>
</Address>
</Facility>
span element can be annotated with names from one's internal namespace, with names from the Data Consortium's
namespace, and with names from a Legalxml namespace. Such an annotated file can be processed directly by tools specific to each namespace
with no transformation required.
This convention allows any particular object to be of multiple types. This convention allows any xml element to represent an object that is a "mix" of multiple types; mix-in classes are distinguished in the Dictionary as "qualified resource types". Due to these mix-in classes, a given xml element can dynamically specify what attributes are appropriate to it.
Business rules relevant to an xml datastream (as to any other format of datastream) are a function of an application for which the rules are being applied. The rules necessary for one application's processing of a given datastream are often different than those necessary for a different application. Given the current state of technology, all business rules cannot yet be parameterized as, say, an xml Schema. This means that the usual case is that most business rules of consequence are enforced in software written specifically for the datastream, that is, by the application itself once the datastream has been initially parsed. In the final analysis, most production-quality applications are written robustly enough that, implicitly, most of the rules that might be recorded in a DTD or xml Schema are re-applied by the software. The logical conclusion is that organizations who standardize a DTD or xml Schema are actually standardizing an interface to a specific application. While this outcome is appropriate for broad-based applications such as Internet browsers, it seems undesirable for all but a handful of domain-specific document types.
The Named Value Notation avoids this problem by not defining a DTD or Schema. Applications are free to establish on their own, internal DTDs and Schema that apply to the information they extract from the xhtml (or other xml) file. The Named Value Notation implements an architecture for document exchange in which source xhtml forms and xhtml documents are validated syntactically against the xhtml DTD, and are validated semantically at a minimum by visual inspection, or more mechanistically by scripts executed during data entry on an xhtml form. This architecture forces all semantic validation of named-values within the dc:names attribute to be performed by one's internal software or DTDs, thus unencumbering the standards process with a burden it need not carry in the first place.
This section defines the contents of tokens in a dotted-name, which fall into these general categories:
Examples: Description.text, GivenName.text,
Identifier.text, BuildingArea.sqft, Height.ft, AdministrativeExpense.usd, NotLaterThanDate.isoExamples: Description.en, Land.Purchased.Cost.usd, Debt.type,
Person.Height.2.pct.of.Person.Height.1.ft,
Facility.OccupiedArea.sqft.per.1.Facility.BuildingArea.sqft,
ReportingPeriod.year, Property.Purchased.iso, Contract.Duration.iso
Examples: Person.Married.1.Date.text,
Property.1.Owner.2.Address.1.City.Name.text, Location.Description.1.text Examples: Document.dc.Title, Property.rdf.ID, Class.rdfs.comment.en, Class.daml.sameClassAs.rdf.ID, Description.xml.lang, Document.xll.href, Person.vc.fn,
Document.Description.xsd.string, Document.html.style Examples: HeatingSystem.type, Fiduciary.Property.1.Worth.amount,
Business.President.Appointed.Date.text Examples: Business.held.Property, Site.contains.Building, Person.memberOf.GroupExamples: Fiduciary.Managed.Property.1, Company.1.Purchased.Property, Person.1.Income.Estimated.Earned.usdExamples: Document.ReportingPeriod.Duration.iso, RealEstate.Quarter.1.Cost.usd,
Property.Current.Retired.Debt.Past.Retired.amount, Names specified in a dc:names attribute shall bear a suffix that indicates its datatype, formatting, units, or language. [Note: this rule can be escaped. See Namespace Tokens.] By convention, all suffixes are lower-case to distinguish them as name-terminators, for the benefit of both human readers and software applications.
<foo dc:names='State.Abbreviation.text'>NY</foo>
// The following xml is one equivalent to the above name.
<State>
<Abbreviation> <text>NY</text> </Abbreviation>
</State>
<foo dc:names='RealEstate.RelatedDocument.Title.en'>Site Survey</foo>
<foo dc:names='RealEstate.RelatedDocument.Title.sp'>Inspección del Sitio</foo>
// The following xml is one equivalent to the above name.
<RealEstate>
<RelatedDocument>
<Title>
<text xml:lang='en'>Site Survey</text>
<text xml:lang='sp'>Inspección del Sitio</text>
</Title>
</RelatedDocument>
</RealEstate>
<foo dc:names='RealEstate.RelatedDocument.Title.en.1'>Site </foo>
<foo dc:names='RealEstate.RelatedDocument.Title.en.2'>Survey </foo>
// The following xml is one equivalent to the above name.
<RealEstate>
<RelatedDocument>
<Title> <en>Site Survey</en> </Title>
</RelatedDocument>
</RealEstate>
<foo dc:names='Facility.OccupiedArea.text'>2,400 square feet</foo>
// The following xml is one equivalent to the above name.
<Facility>
<OccupiedArea> <text>2,400 square feet</text> </OccupiedArea>
</Facility>
<foo dc:names='Region.Population.Census.integer'>480000</foo>
// The following xml is one equivalent to the above name.
<Region>
<Population>
<Census> <integer>480000</integer> </Census>
</Population>
</Region>
<foo dc:names='Region.Population.count'>3</foo>
<foo dc:names='Region.Population.1.Census.integer'>120000</foo>
<foo dc:names='Region.Population.2.Census.integer'>240000</foo>
<foo dc:names='Region.Population.3.Census.integer'>120000</foo>
// The following xml is one equivalent to the above name.
<Region>
<actors'>
<Population id='Region.Population.1'>
<Census> <integer>120000</integer> </Census>
</Population>
<Population id='Region.Population.2'>
<Census> <integer>240000</integer> </Census>
</Population>
<Population id='Region.Population.3'>
<Census> <integer>120000</integer> </Census>
</Population>
</actors'>
</Region>
<foo dc:names='Facility.OccupiedArea.decimal'>2400.00</foo>
// The following xml is one equivalent to the above name.
<Facility>
<OccupiedArea> <decimal>2400.00</decimal> </OccupiedArea>
</Facility>
<foo dc:names='Facility.OccupiedArea.percent.of.BuildingArea'>60.0</foo>
// The following xml is one equivalent to the above name.
<Facility>
<OccupiedArea> <percent of='BuildingArea'>60.0</percent> </OccupiedArea>
</Facility>
<foo dc:names='Facility.OccupiedArea.sqft'>12000</foo>
<foo dc:names='Room.Width.ft'>23</foo>
<foo dc:names='Site.Area.acre'>.55</foo>
<foo dc:names='Facility.DistanceFromTransportation.mi'>2.7</foo>
// The following xml is one equivalent to the above name.
<Facility>
<OccupiedArea> <quantity units='sqft'>12000</quantity> </OccupiedArea>
</Facility>
<Room>
<Width> <quantity units='ft'>23</quantity> </Width>
</Room>
<Site>
<Area> <quantity units='acre'>.55</quantity> </Area>
</Site>
<Facility>
<DistanceFromTransportation> <quantity units='mi'>2.7</quantity> </DistanceFromTransportation>
</Facility>
<foo dc:names='Transaction.ShippingAndHandlingCost.text'>$ 12.50</foo>
// The following xml is one equivalent to the above name.
<Transaction>
<ShippingAndHandlingCost> <text>$ 12.50</text> </ShippingAndHandlingCost>
</Transaction>
<foo dc:names='Transaction.ShippingAndHandlingCost.amount'>12.50</foo>
// The following xml is one equivalent to the above name.
<Transaction>
<ShippingAndHandlingCost> <amount>12.50</amount> </ShippingAndHandlingCost>
</Transaction>
<foo dc:names='Transaction.ShippingAndHandlingCost.usd'>12.50</foo>
// The following xml is one equivalent to the above name.
<Transaction>
<ShippingAndHandlingCost> <amount currency='usd'>12.50</amount> </ShippingAndHandlingCost>
</Transaction>
<foo dc:names='Facility.Rent.usd.per.1.Unit.per.2.month'>1250.00</foo>
// The following xml is one equivalent to the above name. In this encoding, the supporting DTD has an
// element named 'usd', rather than an element named 'amount' which has an attribute named 'currency'.
<Facility>
<Rent>
<Rate per.1='Unit' per.2='Month' usd='1250.00'/>
</Rent>
</Facility>
//which is the same as
<Facility>
<Rent>
<Rate>
<per.1>Unit</per.1>
<per.2>Month</per.2>
<usd>1250.00</usd>
</Rate>
</Rent>
</Facility>
<foo dc:names='Facility.Opened.Date.text'>Wed 12/5/01</foo>
// The following xml is one equivalent to the above name.
<Facility>
<Opened>
<Date> <text>Wed 12/5/01</text> </Date>
</Opened>
</Facility>
<foo dc:names='Document.Received.Timestamp.iso'>2001-12-05T12:30Z</foo>
// The following xml is one equivalent to the above name.
<Document>
<Received>
<Timestamp> <iso>2001-12-05T12:30Z</iso> </Timestamp>
</Received>
</Document>
<foo dc:names='Person.Born.Date.year'>1953</foo>
<foo dc:names='Person.Born.Date.month'>02</foo>
<foo dc:names='Person.Born.Date.day'>28</foo>
<foo dc:names='Person.Born.Time.hour'>22</foo>
<foo dc:names='Person.Born.Time.minute'>30</foo>
<foo dc:names='Person.Born.Time.second'>00</foo>
<foo dc:names='Person.Born.Time.tz'>CST</foo>
<foo dc:names='Person.Born.Duration.iso'>P12H30M</foo>
// - or -
<foo dc:names='Person.Born.year'>1953</foo>
<foo dc:names='Person.Born.month'>02</foo>
<foo dc:names='Person.Born.day'>28</foo>
<foo dc:names='Person.Born.hour'>22</foo>
<foo dc:names='Person.Born.minute'>30</foo>
<foo dc:names='Person.Born.second'>00</foo>
<foo dc:names='Person.Born.tz'>CST</foo>
<foo dc:names='Person.Born.Duration.hour'>12</foo>
<foo dc:names='Person.Born.Duration.minute'>30</foo>
// - alternative time encodings
<foo dc:names='Person.Born.cst'>22:30:00</foo>
<foo dc:names='Person.Born.pm'>10:30:00</foo>
// The following xml is one equivalent to either set of the above names.
<Person>
<Born>
<Date>
<year>1953</year>
<month>02</month>
<day>28</day>
</Date>
<Time>
<hour>22</hour>
<minute>30</minute>
<second>00</second>
<tz>CST</tz>
</Time>
<Duration>
<hour>12</hour>
<minute>30</minute>
</Duration>
</Born>
</Person>
<foo dc:names='Document.asOf'>2001-12-05T12:30Z</foo>
<foo dc:names='Company.Address.asOf'>1998-11-01</foo>
// The following xml is one equivalent to the above name.
<Document asOf='2001-12-05T12:30Z'>
<Company>
<Address asOf='1998-11-01'/>
</Company>
</Document>
The content of "asOf" shall conform to the ISO date/time format and, should a date only be
provided, then midnight is to be the assumed moment during the day. Should a month only
be provided, then midnight on the first day of the month is to be assumed. Should a year only
be provided, then midnight on the first day of the year is to be assumed. It is an error should
a time only be provided. If an hour only is provided, then the zeroth minute of the hour is to be
assumed.
For any specific element, if this attribute is not provided a value, then its value is to be inherited from a parent element in the datastream. If no parent element provides a value for this attribute, then it is to be assigned a value of the moment that the datastream was provided by its publisher. This algorithm allows a publisher to (a) identify the currency of all child elements with a single attribute on their parent element (b) identify those child elements whose currency is an exception to the currency of a parent element. Given that information recorded asOf a certain-date is equally recorded asOf every date since that certain-date, it is logically consistent and correct to default the value of this attribute to the retrieval date/time for the datastream.
It is an error should a parent element have an asOf timestamp that is earlier in time than an asOf timestamp on any one of its child elements.
<foo dc:names='Document.ReportingPeriod.units'>year</foo>
// The following xml is one equivalent to the above names.
<Document>
<ReportingPeriod>
<units>year</units>
</ReportingPeriod>
</Document>
<foo dc:names='Fiduciary.Fund.type'>ClosedEndFund</foo>
// The following xml is one equivalent to the above names.
<Fiduciary>
<Fund> <type>ClosedEndFund</type> </Fund>
</Fiduciary>
<foo dc:names='Fiduciary.RealEstate.Fund.name'>Fiduciary.Fund.3</foo>
// The following xml is one equivalent to the above names.
<Fiduciary>
<RealEstate>
<Fund> <name>Fiduciary.Fund.3</name> </Fund>
</RealEstate>
</Fiduciary>
<foo dc:names='Document.RealEstate.PotentialGrossIncome.usd'>1000.00</foo>
// The following xml is one equivalent to the above name.
<Document>
<RealEstate>
<PotentialGrossIncome> <usd>1000.00</usd> </PotentialGrossIncome>
</RealEstate>
</Document>
An enumeration of the data-entry tokens are located in the Data Consortium Dictionary as subclasses of the Entry class.
Its immediate subclasses are the Memo, Quantity, and Time classes (in addition to the QualifiedEntry class);
these classes correspond to the names for text values, numeric values, and date/time values. In other words, all attributes that resolve to a string, not to an object reference,
are defined as a subclass of the Entry class.
<foo dc:names='Facility.DiningRoom.Area.type'>Small</foo>
// The following xml is one equivalent to the above names.
<Facility>
<DiningRoom>
<Area> <type>Small</type> </Area>
</DiningRoom>
</Facility>
Source: http://search.dataconsortium.org
Entry
QualifiedEntry
MethodQualifiedEntry
TimeQualifiedEntry
UseQualifiedEntry
Memo
Block
Description
Feature
Access
Color
Environment
Orientation
PersonalFeature
Right
Safety
Shape
Style
Identifier
Method
MeasurementMethod
Quantity
QualifiedQuantity
Amount
QualifiedAmount
AccountingEntry
QualifiedAccountingEntry
Asset
Equity
Expense
Income
Liability
TransactionEntry
Adjustment
Charge
Cost
Revenue
Value
Interest
Price
Profit
Rent
Worth
Count
Index
Measurement
Percentage
Probability
Range
Time
Date
QualifiedDate
EndDate
EventDate
StartDate
Duration
Period
TimeSeries
|
Root class for all textual attributes Root class for general qualifiers for entries EstimatedEntry CalculatedEntry BudgetedEntry CorrectedEntry ... PreviousEntry CurrentEntry FutureEffectiveEntry LatestEntry ... AuditorEntry Root class for all string attributes ... Footer Header ImageBlock Line List Page Section Sound TextBlock ... Name Note Rank and Type HandicappedAccess RestrictedAccess Sensitivity etc Approximately 160 generic colors are subclasses Arid Calm Clean Clear Cold Cool Damp ... Atop Backwards Corner East Exterior ... Ethnicity EyeColor Gender Hair HairColor HairLength etc ... LendeeRight LenderRight LesseeRight LessorRight OwnerRight ... Dangerous Fireproof Fireresistant Potable Safe ... Bayshape Bevel Bullnose Circular Elliptical Concave ... ConstructionStyle DesignStyle ... Address Combination InstitutionID LicenseNumber ... Class for names of methods and processes EnglishMeasurement MetricMeasurement Root class for all numeric attributes Root class for all financial amounts AuthorizedAmount BudgetedAmount CommittedAmount ObligatedAmount ... Root class for entries that are made to financial accounts AdjustingEntry ClosingEntry ExtraordinaryEntry OpeningEntry ... AmountReceivable BeforetaxEquityReversion BookValue ImpliedEquityMarketCap ... LeveragedEquity PlottageValue SweatEquity UnleveragedEquity ... BusinessExpense FacilityExpense GeneralAndAdministrativeExpense LaborExpense ... BusinessIncome OperatingIncome QualifiedIncome ServiceIncome ... AmountPayable DebtFinancing DebtService OutstandingDebt TotalLiability ... Root class for entries that are involved with a transaction Credit Debit Discount etc Compensation (BonusPay ...) Fee (AdministrativeFee ConstructionFee FinancialFee ...) ... QualifiedCost ProductCost SalesCost TaxCost ... QualifiedRevenue ProductRevenue SalesRevenue TaxRevenue ... Root class for entries that express a simple financial value AccruedInterest CompoundInterest CreditCardInterest MortgageInterest SimpleInterest etc InsurancePremium QualifiedPrice UnitPrice BuildingShellRent DoubleNetRent FlatRent GroundRent IndexedRent StepRent ... MarketValue PresentValue TaxValue ... ... ConsumerPriceIndex CostOfLivingIndex HousingAffordabiityIndex ParkingIndex ... Area Capacity Density Distance Frequency Gradient Speed Temperature ... AmortizationRate AssessmentRatio AverageAskingLeaseRate CaptureRate ... CreditScore MarketRentalRisk RenewalProbability ... Root class for all time-related attributes EarliestDate LatestDate NotLaterThanDate ClosingDate Deadline DelinquencyDate YearBuilt ... AnniversaryDate AppraisalDate AsofDate CommitmentDate DueDate ... CreationDate LeaseCommencementDate OccupancyDate Age AgeOfFacilities AverageDowntime EconomicAge LegalAge LifeOfLoan ... AbsorptionPeriod ... AmortizationPeriod BalloonPeriod BasePeriod ... |
<foo dc:names='PropertyManager.LastName.text'>Lincoln</foo>
<foo dc:names='QuarterlyREIFReport.ReportingPeriod.EndDate.iso'>2002-03-31</foo>
<foo dc:names='HighRiseBuilding.Height.ft'>1235</foo>
<foo dc:names='HeatingSystem.type'>ForcedAirHeatingSystem</foo>
<foo dc:names='LowRiseOfficeProperty .Developed.Date.year'>1967</foo>
// The following xml is one equivalent to the above names.
<PropertyManager>
<LastName> <text>Lincoln</text> <LastName>
</PropertyManager>
<QuarterlyREIFReport>
<ReportingPeriod>
<EndDate> <iso>2002-03-31</iso> <EndDate>
</ReportingPeriod>
</QuarterlyREIFReport>
<HighRiseBuilding>
<Height> <ft>1235</ft> <Height>
</HighRiseBuilding>
<HeatingSystem>
<type>1235</type>
</HeatingSystem>
<LowRiseOfficeProperty>
<Developed>
<Date> <year>1967</year> <Date>
</Developed>
</LowRiseOfficeProperty>
<foo dc:names='RealEstate.Name.text'>Sears Block</foo>
<foo dc:names='RealEstate.Site.Name.text'>Sears Tower Complex</foo>
<foo dc:names='RealEstate.Site.Building.Name.text'>Sears Tower</foo>
<foo dc:names='RealEstate.Site.Building.Floor.Name.text'>12th Floor</foo>
<foo dc:names='RealEstate.Site.Building.Floor.Unit.Name.text'>Suite 1232</foo>
<foo dc:names='RealEstate.Site.Building.Floor.Unit.Room.Name.text'>Reception</foo>
// The following xml is one equivalent to the above names.
<RealEstate>
<Name> <text>Sears Block</text> </Name>
<Site>
<Name> <text>Sears Tower Complex</text> </Name>
<Building>
<Name> <text>Sears Tower</text> </Name>
<Floor>
<Name> <text>12th Floor</text> </Name>
<Unit>
<Name> <text>Suite 1232</text> </Name>
<Room>
<Name> <text>Reception</text> </Name>
</Room>
</Unit>
</Floor>
</Building>
</Site>
</RealEstate>
<foo dc:names='RealEstate.Purchased.1.Seller.Name.text'>George Washington</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.1.Name.text'>John Adams</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.2.Name.text'>Abigail Adams</foo>
// The following xml is one equivalent to the above names.
// Note that the id attribute contains the named-value name, functioning like an XPATH expression.
<RealEstate>
<Purchased id='RealEstate.Purchased.1'>
<Seller>
<Name> <text>George Washington</text> </Name>
</Seller>
</Purchased>
<Purchased id='RealEstate.Purchased.2'>
<Seller id='RealEstate.Purchased.2.Seller.1'>
<Name> <text>John Adams</text> </Name>
</Seller>
<Seller id='RealEstate.Purchased.2.Seller.2'>
<Name> <text>Abigail Adams</text> </Name>
</Seller>
</Purchased>
</RealEstate>
Index tokens are 1-based, that is, the zero'th index value is reserved for use by application software. Index tokens should be consecutively assigned from "1".
Note that the suffix, ".count", can be meaningfully specified by a datastream, as in <foo dc:names='RealEstate.Purchased.count'>2</foo>
<foo dc:names='RealEstate.Purchased.1.Seller.Name.text'>George Washington</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.1.Name.text'>John Adams</foo>
<foo dc:names='RealEstate.Purchased.2.Seller.2.Name.text'>Abigail Adams</foo>
// The following xml is one equivalent to the above names.
<RealEstate>
<events name='Purchased' count='2'>
<Purchased id='RealEstate.Purchased.1'>
<Seller>
<Name> <text>George Washington</text> </Name>
</Seller>
</Purchased>
<Purchased id='RealEstate.Purchased.2'>
<Seller id='RealEstate.Purchased.2.Seller.1'>
<Name> <text>John Adams</text> </Name>
</Seller>
<Seller id='RealEstate.Purchased.2.Seller.2'>
<Name> <text>Abigail Adams</text> </Name>
</Seller>
</Purchased>
</events>
</RealEstate>
Optional qualifier tokens apply to all nouns defined in the dictionary, that is, to names of principal and dependent resource-types, event names, and data-entry names. Two types of qualifiers are defined: events and topics For data-entry names, the qualifiers follow the name, while for all other nouns, qualifiers precede the name.
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.usd'>12345</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Revised.Estimated.usd.per.1.BuildingArea.sqft'>12.35</foo>
// The following xml is one equivalent to the above names.
// Typing information and events have been inserted based upon the qualifiers in the name.
<RealEstate>
<AdministrativeExpense>
<type>Estimate</type>
<usd>12345</usd>
<Estimated/>
</AdministrativeExpense>
<AdministrativeExpense>
<type>Revision</type>
<Revised/>
<type>Estimate</type>
<Estimated/>
<Rate per.1='BuildingArea.sqft'> <usd>12.35</usd> <Rate>
</AdministrativeExpense>
</RealEstate>
The table below shows the event-qualifiers that can be specified for numeric quantities. It is arranged as a taxonomy, meaning
that a given Entry-type inherits event-qualifiers applicable to its superclasses. For instance, the set of event-qualifiers that
may be specified for Income includes: Assumed, Managed, Planned, Recorded, Revised
Contracted, Offered, Proposed, Adjusted, Annualized, Averaged, Calculated, Estimated, Forecasted,
Maximized, Minimized, Normalized, Projected, Prorated, Rounded,
Converted, Netted, Totalled, Entered, Reversed, Earned, Owed, and Paid.
| Event/Quantity Taxonomy | Events that may be used as a qualifier for each type. |
|---|---|
Resource
Entry
Quantity
Amount
AccountingEntry
Asset
Equity
Expense
Income
Liability
TransactionEntry
Adjustment
Charge
Cost
Revenue
Value
Fee
Interest
Price
Rent
Worth
|
Archived, Assumed, Managed, Planned, Recorded, Revised Contracted, Offered, Proposed Adjusted, Annualized, Averaged, Calculated, Estimated, Extrapolated, Forecasted, Interpolated, Maximized, Minimized, Normalized, Projected, Prorated, Rounded Converted, Netted, Totalled Credited, Debited, Entered, Reversed Earned, Owed, Paid Incurred, Retired Budgeted Applied Invoiced, Rescinded Appropriated, Committed, Obligated, Expended, Disbursed Tendered |
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.usd.per.1.BuildingArea.sqft'>12.35</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.Description.text'>Assumptions are from ...</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.Date.iso'>2001-01-31</foo>
// For a contrast, here is a description of the expense itself...
<foo dc:names='RealEstate.AdministrativeExpense.Description.text'>Includes these expenses ...</foo>
// The following xml is one equivalent to the above names.
<RealEstate>
<AdministrativeExpense>
<type>Estimate</type>
<Rate per.1='BuildingArea.sqft'> <usd>12.35</usd> </Rate>
<Estimated>
<Description> <text>Assumptions are from ...</text> </Description>
<Date> <iso>2002-01-31</iso> </Date>
</Estimated>
<Description> <text>Includes these expenses ...</text> </Description>
</AdministrativeExpense>
</RealEstate>
<foo dc:names='Fiduciary.Managed.RealEstate.1.TaxAssessment.usd'>1250000.00</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.AssessmentTax.usd'>7500.00</foo>
<foo dc:names='Fiduciary.Managed.Distressed.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>
// The following xml is one equivalent to the above names.
<Fiduciary>
<RealEstate id='Fiduciary.Managed.RealEstate.1'>
<TaxAssessment> <usd>1250000.00</usd> </TaxAssessment>
<AssessmentTax> <usd>7500.00</usd> </AssessmentTax>
<Managed/>
</RealEstate>
<RealEstate id='Fiduciary.Managed.Distressed.RealEstate.1'>
<TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
<Managed/>
<Distressed/>
</RealEstate>
</Fiduciary>
In the sample above, qualifiers are implied to be attributes of the resource, in order that it be selected. This fact must be observed when the
qualifiers are to have attributes themselves.
<foo dc:names='Fiduciary.Managed.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.Managed.Started.Date.year'>1987</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.Managed.Stopped.Date.year'>2002</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.Managed.Manager.TelephoneNumber.text'>202-555-1212</foo>
// The following xml is one equivalent to the above names.
<Fiduciary>
<RealEstate id='Fiduciary.Managed.RealEstate.1'>
<TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
<Managed>
<Started> <Date> <year>1987</year> </Date> </Stopped>
<Stopped> <Date> <year>2002</year> </Date> </Stopped>
<Manager>
<TelephoneNumber> <text>202-555-1212</text> </TelephoneNumber>
</Manager>
</Managed>
</RealEstate>
</Fiduciary>
This implements a consistent model because the alternative approach is to first associate a property with the fiduciary, and then reference it as a qualified resource.
<foo dc:names='Fiduciary.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>
<foo dc:names='Fiduciary.RealEstate.1.Managed.Started.Date.year'>1987</foo>
<foo dc:names='Fiduciary.RealEstate.1.Managed.Stopped.Date.year'>2002</foo>
<foo dc:names='Fiduciary.RealEstate.1.Managed.Manager.TelephoneNumber.text'>202-555-1212</foo>
<foo dc:names='Fiduciary.Managed.RealEstate.1.name'>Fiduciary.RealEstate.1</foo>
// The following xml is one equivalent to the above names.
<Fiduciary>
<RealEstate id='Fiduciary.RealEstate.1'>
<TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
<Managed>
<Started> <Date> <year>1987</year> </Date> </Stopped>
<Stopped> <Date> <year>2002</year> </Date> </Stopped>
<Manager>
<TelephoneNumber> <text>202-555-1212</text> </TelephoneNumber>
</Manager>
</Managed>
</RealEstate>
<RealEstate id='Fiduciary.Managed.RealEstate.1' idref='Fiduciary.RealEstate.1'/>
</Fiduciary>
<foo dc:names='Actors.Person.1.TelephoneNumber.text''>202-555-1212</foo>
<foo dc:names='Fiduciary.ActiveProperties.RealEstate.1.TaxAssessment.usd'>3500000.00</foo>
<foo dc:names='Fiduciary.ActiveProperties.RealEstate.1.Manager.name>Actors.Person.1</foo>
// The following xml is one equivalent to the above names.
<Actors>
<Person id='Actors.Person.1'>
<TelephoneNumber> <text>202-555-1212</text> </TelephoneNumber>
</Person >
</Actors>
<Fiduciary>
<ActiveProperties>
<RealEstate id='Fiduciary.ActiveProperties.RealEstate.1'>
<TaxAssessment> <usd>3500000.00</usd> </TaxAssessment>
<Manager idref='Actors.Person.1'/>
</RealEstate>
</ActiveProperties>
</Fiduciary>
<foo dc:names='RealEstate.Quarter.1.EndDate.iso'>2001-03-31</foo>
<foo dc:names='RealEstate.Quarter.1.AdministrativeExpense.usd.per.1.BuildingArea.sqft'>12.35</foo>
<foo dc:names='RealEstate.Year.1.year'>2002</foo>
<foo dc:names='RealEstate.Year.1.Quarter.1.AdministrativeExpense.Estimated.usd'>12345.00</foo>
<foo dc:names='RealEstate.Year.1.Quarter.2.AdministrativeExpense.Estimated.usd'>23451.00</foo>
<foo dc:names='RealEstate.Year.1.Quarter.3.AdministrativeExpense.Estimated.usd'>34512.00</foo>
<foo dc:names='RealEstate.Year.1.Quarter.4.AdministrativeExpense.Estimated.usd'>45123.00</foo>
// The following xml is one equivalent to the above names.
<RealEstate>
<Quarter id='RealEstate.Quarter.1>
<EndDate> <iso>2001-03-31</iso> </EndDate>
<AdministrativeExpense>
<type>Estimate</type>
<Estimated/>
<Rate per.1='BuildingArea.sqft'> <usd>12.35</usd> </Rate>
</AdministrativeExpense>
</Quarter>
<Year id='RealEstate.Year.1'>
<year>2002</year>
<Quarter id='RealEstate.Year.1.Quarter.1'>
<AdministrativeExpense>
<type>Estimate</type>
<usd>12345.00</usd>
<Estimated/>
</AdministrativeExpense>
</Quarter>
<Quarter id='RealEstate.Year.1.Quarter.2'>
<AdministrativeExpense>
<type>Estimate</type>
<usd>23451.00</usd>
<Estimated/>
</AdministrativeExpense>
</Quarter>
<Quarter id='RealEstate.Year.1.Quarter.3'>
<AdministrativeExpense>
<type>Estimate</type>
<usd>34512.00</usd>
<Estimated/>
</AdministrativeExpense>
</Quarter>
<Quarter id='RealEstate.Year.1.Quarter.4'>
<AdministrativeExpense>
<type>Estimate</type>
<usd>45123.00</usd>
<Estimated/>
</AdministrativeExpense>
</Quarter>
</Year>
</RealEstate>
Due to the amount of repeated information, the sample above can be cumbersome as more time periods are added, or as more types of expenses are
reported. To address this, a resource's "ReportingPeriod" can anchor time-expressions — if a resource does not define its own reporting period,
then it defaults to the reporting period(s) defined for its parent elements, to the level of the document.
<foo dc:names='RealEstate.ReportingPeriod.1.BeginDate.iso'>2001-01-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.2.BeginDate.iso'>2002-01-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.3.BeginDate.iso'>2002-04-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.4.BeginDate.iso'>2002-07-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.5.BeginDate.iso'>2002-10-01</foo>
<foo dc:names='RealEstate.ReportingPeriod.1.EndDate.iso'>2001-03-31</foo>
<foo dc:names='RealEstate.ReportingPeriod.2.EndDate.iso'>2002-03-31</foo>
<foo dc:names='RealEstate.ReportingPeriod.3.EndDate.iso'>2002-06-30</foo>
<foo dc:names='RealEstate.ReportingPeriod.4.EndDate.iso'>2002-09-31</foo>
<foo dc:names='RealEstate.ReportingPeriod.5.EndDate.iso'>2002-12-31</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.1.usd.per.1.BuildingArea.sqft'>12.35</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.2.usd'>12345.00</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.3.usd'>23451.00</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.4.usd'>34512.00</foo>
<foo dc:names='RealEstate.AdministrativeExpense.Estimated.ReportingPeriod.5.usd'>45123.00</foo>
// The following xml is one equivalent to the above names.
<RealEstate>
<ReportingPeriod id='ReportingPeriod.1'>
<BeginDate> <iso>2001-01-01</iso> </BeginDate>
<EndDate> <iso>2001-03-31</iso> </EndDate>
</ReportingPeriod>
<ReportingPeriod id='ReportingPeriod.2'>
<BeginDate> <iso>2002-01-01</iso> </BeginDate>
<EndDate> <iso>2002-03-31</iso> </EndDate>
</ReportingPeriod>
<ReportingPeriod id='ReportingPeriod.3'>
<BeginDate> <iso>2002-04-01</iso> </BeginDate>
<EndDate> <iso>2002-06-30</iso> </EndDate>
</ReportingPeriod>
<ReportingPeriod id='ReportingPeriod.4'>
<BeginDate> <iso>2002-07-01</iso> </BeginDate>
<EndDate> <iso>2002-09-31</iso> </EndDate>
</ReportingPeriod>
<ReportingPeriod id='ReportingPeriod.5'>
<BeginDate> <iso>2002-10-01</iso> </BeginDate>
<EndDate> <iso>2002-12-31</iso> </EndDate>
</ReportingPeriod>
<AdministrativeExpense>
<type>Estimate</type>
<Estimated/>
<Rate per.1='BuildingArea.sqft'> <usd time='ReportingPeriod.1'>12.35</usd> </Rate>
<usd time='ReportingPeriod.2'>12345.00</usd>
<usd time='ReportingPeriod.3'>23451.00</usd>
<usd time='ReportingPeriod.4'>34512.00</usd>
<usd time='ReportingPeriod.5'>45123.00</usd>
</AdministrativeExpense>
</RealEstate>
An escaping notation is provided by reserved tokens that signal specific xml namespaces. This feature provides access to xml elements and attributes defined by the namespace. The xml namespaces supported by this feature include
<foo dc:names='Document.rdf.ID'>http://www.dot.com/Valuation.2001-12-31.html</foo>
<foo dc:names='Document.rdf.type'>dc:ValuationReport</foo> <!–– assign type from Dictionary to instance––>
<foo dc:names='Document.rdf.Description'/> <!–– create resource as child of instance––>
<foo dc:names='Document.rdf.RDF'/> <!–– start RDF datastream as child of instance.––>
These statements can be coded directly, using an rdf:names attribute on the foo element, with the provisio that they must appear on an element
that is within scope of a parent resource element. See xhtml Markup Rules for more information about setting scope.
<foo rdf:names='ID'>http://www.dot.com/Valuation.2001-12-31.html</foo>
<foo rdf:names='type'>dc:ValuationReport</foo> <!–– assign type from Dictionary to instance––>
<foo rdf:names='Description'> <!–– create resource as child of instance––>
<foo rdf:names='RDF'> <!–– start RDF datastream as child of instance.––>
<foo dc:names='Resource.rdfs.Class.rdf.ID'>ArgusValuationReport</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.subClassOf'>dc:ValuationReport</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.label'>My Argus Valuation Document</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.comment'>Subclasses dc:ValuationReport class.</foo>
<foo dc:names='Resource.rdfs.Class.rdf.ID'>ArgusID</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.subClassOf'>dc:Identifier</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.label'>Argus Identifier</foo>
<foo dc:names='Resource.rdfs.Class.rdfs.comment'>Argus identifier from page 1 of output.</foo>
<foo dc:names='Resource.rdf.Property.rdfs.subPropertyOf'></foo>
<foo dc:names='Resource.rdf.Property.rdfs.label'>ArgusValuationReport.ArgusID</foo>
<foo dc:names='Resource.rdf.Property.rdfs.comment'>Associate A new property.</foo>
<foo dc:names='Resource.rdf.Property.rdfs.range>ArgusID</foo>
<foo dc:names='Resource.rdf.Property.rdfs.domain>ArgusValuationReport</foo>
Class definition statements can be coded directly, using an rdfs:names attribute on the foo element, with the provisio that they must appear within
the scope of a resource. For instance<foo rdfs:names='Class.rdf.ID'>ArgusID</foo>
<foo rdfs:names='Class.rdfs.subClassOf'>dc:Identifier</foo>
<foo rdfs:names='Class.rdfs.label'>Argus Identifier</foo>
<foo rdfs:names='Class.rdfs.comment'>Argus' identifier from page 1 of output.</foo>
Within the scope of a rdfs:Class, relevant terms can be coded without qualification. <foo rdfs:names='subClassOf'>dc:ValuationReport</foo>
<foo rdfs:names='label'>Argus Identifier</foo>
<foo rdfs:names='comment'>Argus identifier from page 1 of output.</foo>
Similarly, within the scope of a rdf:Property, relevant terms can be coded without qualification. <foo rdfs:names='subPropertyOf'></foo>
<foo rdfs:names='label'>Argus Identifier</foo>
<foo rdfs:names='comment'>Argus identifier from page 1 of output.</foo>
<foo rdfs:names='range'>ArgusID</foo>
<foo rdfs:names='domain'>ArgusValuationReport</foo>
<foo dc:names='Resource.xml.id'>put-single-token-here</foo>
<foo dc:names='Resource.xml.lang'>en</foo>
<foo dc:names='Resource.xml.base'>put-base-uri-here.</foo>
<foo dc:names='Resource.xmlns.xxx'>put-namespace-uri-here.</foo>
<foo dc:names='Resource.Class.daml.sameClassAs'>dc:SomeClassName</foo>
<foo dc:names='Resource.xsi.type'>Document</foo>
<foo dc:names='Document.dc.Title'>Portfolio Valuations, as of Dec 31, 2001</foo>
<foo dc:names='Document.dc.Creator'>Commercial Real Estate Management, Inc.</foo>
<foo dc:names='Document.dc.Contributor'>US Dept of Commerce</foo>
<foo dc:names='Document.dc.Coverage'>Active Properties in Portfolio, 12-31-2001</foo>
<foo dc:names='Document.dc.Date'>2001-12-31</foo>
<foo dc:names='Document.dc.Description'>This valuation uses 12/01/01 assumptions.</foo>
<foo dc:names='Document.dc.Format'>text/xml</foo>
<foo dc:names='Document.dc.Identifier'>http://www.dot.com/Valuation.2001-12-31.html</foo>
<foo dc:names='Document.dc.Language'>EN</foo>
<foo dc:names='Document.dc.Publisher'>Internet Publishing Company</foo>
<foo dc:names='Document.dc.Rights'>dc:AllRightsReserved</foo>
<foo dc:names='Document.dc.Relation'>http://www.dot.com/Valuation.2001-06-30.html</foo>
<foo dc:names='Document.dc.Source'>Argus</foo>
<foo dc:names='Document.dc.Subject'>Real Estate</foo>
<foo dc:names='Document.dc.Type'>dc:ValuationReport</foo>
<foo dc:names='Resource.html.class'>put CSS selector names here </foo>
<foo dc:names='Resource.html.style'>put html style attribute value here.</foo>
<foo dc:names='Resource.html.dir'>put html writing direction here.</foo>
<foo dc:names='Resource.wsdl.???'>???</foo>
<foo dc:names='Resource.xsd.string'>some string</foo>
<foo dc:names='Resource.xsd.boolean'>true</foo>
<foo dc:names='Resource.xsd.decimal'>1.0</foo>
<foo dc:names='Resource.xsd.float'>12.78e-2</foo>
<foo dc:names='Resource.xsd.double'>1267.43233E12</foo>
<foo dc:names='Resource.xsd.duration'>P0Y1347M0D</foo>
<foo dc:names='Resource.xsd.dateTime'>1999-05-31T13:20:00-05:00</foo>
<foo dc:names='Resource.xsd.time'>13:20:00-05:00</foo>
<foo dc:names='Resource.xsd.date'>1999-05-31</foo>
<foo dc:names='Resource.xsd.gYearMonth'>1999-05</foo>
<foo dc:names='Resource.xsd.gYear'>1999</foo>
<foo dc:names='Resource.xsd.gMonthDay'>05-31</foo>
<foo dc:names='Resource.xsd.gDay'>31</foo>
<foo dc:names='Resource.xsd.gMonth'>05</foo>
<foo dc:names='Resource.xsd.hexBinary'>0FB7</foo>
<foo dc:names='Resource.xsd.base64Binary'>...</foo>
<foo dc:names='Resource.xsd.anyURI'>http://www.dataconsortium.org</foo>
<foo dc:names='Resource.xsd.QName'>dc:ValuationReport</foo>
Alternatively, an xsd:names attribute can be used, referencing the namespace identified by URI:
http://www.w3.org/2001/XMLSchema-datatypes.
<foo xsd:names='string'>some string</foo>
<foo xsd:names='boolean'>true</foo>
<foo xsd:names='decimal'>1.0</foo>
<foo xsd:names='float'>12.78e-2</foo>
<foo xsd:names='double'>1267.43233E12</foo>
<foo xsd:names='duration'>P0Y1347M0D</foo>
<foo xsd:names='dateTime'>1999-05-31T13:20:00-05:00</foo>
<foo xsd:names='time'>13:20:00-05:00</foo>
<foo xsd:names='date'>1999-05-31</foo>
<foo xsd:names='gYearMonth'>1999-05</foo>
<foo xsd:names='gYear'>1999</foo>
<foo xsd:names='gMonthDay'>05-31</foo>
<foo xsd:names='gDay'>31</foo>
<foo xsd:names='gMonth'>05</foo>
<foo xsd:names='hexBinary'>0FB7</foo>
<foo xsd:names='base64Binary'>...</foo>
<foo xsd:names='anyURI'>http://www.dataconsortium.org</foo>
<foo xsd:names='QName'>dc:ValuationReport</foo>
<foo dc:names='Resource.xll.type'>simple</foo>
<foo dc:names='Resource.xll.show'>new</foo>
<foo dc:names='Resource.xll.actuate'>onRequest</foo>
<foo dc:names='Resource.xll.title'>Views of the Property</foo>
<foo dc:names='Resource.xll.role'>pictureList</foo>
<foo dc:names='Resource.xll.href'>put a URL here</foo>
Alternatively, an xll:names attribute can be used, referencing the namespace identified by URI:
http://www.w3.org/1999/xlink.
<foo xll:names='type'>simple</foo>
<foo xll:names='show'>new</foo>
<foo xll:names='actuate'>onRequest</foo>
<foo xll:names='title'>Views of the Property</foo>
<foo xll:names='role'>pictureList</foo>
<foo xll:names='href'>put a URL here</foo>
<foo dc:names='Actor.vc.fn'>John Quincy Adams</foo>
This section provides rules for and examples of the use of the dotted-name convention within Extensible html (xhtml) files. A Modular HTML specification will be created (see Modularization of XHTML™ in XML Schema).
The first step in a datastream that uses the dotted-name conventions is to declare the namespace that is used as a prefix to the names attribute placed onto <foo> elements. The xml Namespace facility allows any name for the prefix to be assigned.
<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
<body>
<span>Report Begin Date:</span>
<span pfx:names='Document.ReportingPeriod.1.BeginDate.iso'>2001-01-01</span>
</body>
</html>
The next step is to declare the type of document that is being represented. There are two places conventionally where this information is specified for the
benefit of receiving software: the <body> and <form> elements.
<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
<body pfx:names='QuarterlyREIFReport'>
<span>Report Begin Date:</span>
<span pfx:names='Document.ReportingPeriod.1.BeginDate.iso'>2001-01-01</span>
</body>
</html>
When nested elements in the datastream each have dotted-names attached to them, then it may be assumed that the nested element's names are qualified by its parent elements' names.
For the sample, software can implicitly interpret
<foo pfx:names='Document.ReportingPeriod.1.BeginDate.iso'/> as <foo pfx:names='QuarterlyREIFReport.Document.ReportingPeriod.1.BeginDate.iso'>.
However, because a "QuarterlyREIFReport" is a "Document", then it inherits its superclasses' attributes. Software must interpret "QuarterlyREIFReport.Document..." as "QuarterlyREIFReport...". This rule holds for consecutive terms, where the lagging term is a name of a "type" assigned to the leading term.
A namespace qualified names attribute may contain more than one name for the element's text content. An unqualified names attribute is not acceptable. A name attribute can also be used in the context of forms.
<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
<body pfx:names='QuarterlyREIFReport'>
<span>Report Begin Date:</span>
<span pfx:names='Document.ReportingPeriod.1.BeginDate.iso'>2001-01-01</span>
<h1 pfx:names='Document.Title.text Document.dc.Title'>Quarterly Real Estate Investment Fiduciary Report</h1>
</body>
</html>
The text content for an element bearing a names attribute may be provided in different ways. For <input> elements, the value attribute contains the text to assign to the named value. For <select> elements, the value attribute on its child <option> element bearing a selected attribute is used. Below, one of the <option> elements contains an empty string, meaning that no assignment is to be made to the named value. There is no difference between an empty string and a non-existent value attribute.
<html xmlns:pfx='http://www.dataconsortium.org/Dictionary.rdf'>
<body pfx:names='QuarterlyREIFReport'>
<!-- show the coding for any <input> element -->
<input pfx:names='Document.dc.Date Document.ReportingPeriod.1.BeginDate.iso'
type='hidden'value='2001-01-01'/>
<!-- show the coding for an <h1> element -->
<h1 pfx:names='Document.Title.text Document.dc.Title'>
Quarterly Real Estate Investment Fiduciary Report
</h1>
<!-- show the coding for a <select> element -->
<select pfx:names='Document.type'>
<option value='' selected='selected'>Quarterly Status</option>
<option value='YearEndReport'>Year-end Report</option>
</select>
</body>
</html>
| ↓ A.B → | Actor | Document | Entry | Event | Location | Product | Property | Service | Topic |
|---|---|---|---|---|---|---|---|---|---|
| Actor | A.isA.B A.partOf.B | A.saidBy.B | A.had.B | A.changedBy.B | A.held.B | A.provided.B | A.describedBy.B | ||
| Document | A.said.B | A.isA.B A.partOf.B | A.said.B | ||||||
| Entry | A.hadBy.B | A.isA.B A.partOf.B | A.hadBy.B | ||||||
| Event | A.changed.B | A.isA.B A.partOf.B | A.changed.B | ||||||
| Location | A.heldBy.B | A.saidBy.B | A.had.B | A.changedBy.B | A.isA.B A.partOf.B | A.held.B | A.is.B | A.provided.B | |
| Product | A.heldBy.B | A.isA.B A.partOf.B | |||||||
| Property | A.is.B | A.isA.B A.partOf.B | |||||||
| Service | A.providedBy.B | A.providedBy.B | A.isA.B A.partOf.B | ||||||
| Topic | A.described.B | A.described.B | |||||||