[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Automating ebXML Search Interfaces
***************************************************************************** The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. *****************************************************************************
AUTOMATIC GENERATION OF
ebXML SEARCH INTERFACES
John
Petit
KPMG XMLfs Group and 4thWORLD Telecom
Within the ebXML specification we need to provide a clear way for users to
search for information across distributed repositories. This means that the
ebXML spec should provide for the automatic generation of search interfaces.
Independent search engines need to interpret an ebXML DTD and present a query
interface based on that DTD. The question is: how is the search engine to
interpret the DTD and build an intelligent interface based on that DTD? Simply
listing every element in the DTD is one approach, but an ugly one. Many DTDs
will contain numerous elements which would only clutter and confuse a search
interface. There is no way to determine from an aesthetic and human interface
point of view what such an interface should look like. Therefore, I propose that
we add an optional processing instruction within ebXML schemas and DTDs for an
XSL stylesheet that when processed would display a search interface. In this
way, those that design DTDs could also design the search interface for the
documents associated with that DTD. The DTD and, optionally, the XSL stylesheet
would be uploaded to the registry.
Applications accessing the registered DTD would then have the option of
processing the stylesheet.
It should be quite evident that simply analyzing the real estate DTD below (figure 2) would not generate an interface such as the one in figure 1. In this particular interface the designer has provided a mechanism by which the interface can expand to allow multiple search parameters across multiple geographical areas (the “Additional Group” button). In addition, most of the items in this interface are constrained by pop-up menus. For example, clicking on the country would display a list of countries that utilize the DTD. That in turn would determine the format for the following buttons such as state. In this case, the country is the USA, so the state pop up would list the states. Such constraint is important for accurate matches. Clearly it would be next to impossible to produce such an intelligent interface based on the DTD alone. JavaScript (for example) could provide the programming horsepower behind such interfaces.
figure 2 Real Estate Listing DTD
<!--
Parameter Entities -->
<!-- Notation Declarations
-->
<!ELEMENT RESIDENTIAL-LISTING
(GENERAL,FEATURES,FINANCIAL,REMARKS,CONTACTS) >
<!--
***************************************************************
-->
<!ELEMENT APN (#PCDATA) >
<!ELEMENT MLS (MLS-CODE,MLS-SOURCE?) >
<!ELEMENT MLS-CODE (#PCDATA) >
<!ELEMENT MLS-SOURCE (%NAME;,%PFW;) >
<!ELEMENT TYPE (#PCDATA) >
<!ELEMENT PRICE (#PCDATA) >
<!ELEMENT WHEN-BUILT (ORIGINAL-STRUCTURE, IMPROVEMENTS*)
>
<!ELEMENT ORIGINAL-STRUCTURE (#PCDATA) >
<!ELEMENT IMPROVEMENTS (#PCDATA) >
<!ELEMENT LOCATION (%ACZ;,ROUGH?) >
<!ELEMENT ROUGH (#PCDATA) >
<!ELEMENT STRUCTURE ((NUM-BEDS|NUM-BATHS|SUPER-STRUCTURE|%BA;)*)
>
<!ELEMENT NUM-BEDS (#PCDATA) >
<!ELEMENT NUM-BATHS (#PCDATA) >
<!-- If the property in question is a condo or such, SUPER-STRUCTURE is
used -->
<!ELEMENT BUILDING-AREA (#PCDATA) >
<!ELEMENT NUM-UNITS (#PCDATA) >
<!ELEMENT NUM-FLOORS (#PCDATA) >
<!ELEMENT ADD-INFO (#PCDATA)
<!ELEMENT DATES (LISTING-DATE,LAST-MODIFIED,EXPIRATION-DATE)
>
<!ELEMENT LISTING-DATE (#PCDATA) >
<!ELEMENT LAST-MODIFIED (#PCDATA) >
<!ELEMENT EXPIRATION-DATE (#PCDATA) >
<!ELEMENT LAND-AREA (#PCDATA) >
<!ELEMENT STATUS (#PCDATA) >
<!ELEMENT TERMS (#PCDATA) >
<!--
***************************************************************
-->
<!ELEMENT DISCLOSURES (#PCDATA) >
<!ELEMENT UTILITIES (#PCDATA) >
<!ELEMENT EXTRAS (#PCDATA) >
<!ELEMENT CONSTRUCTION (#PCDATA) >
<!ELEMENT ACCESS (#PCDATA) >
<!--
***************************************************************
-->
<!ELEMENT ASSUMABLE (#PCDATA) >
<!ELEMENT OWNER-CARRY (#PCDATA) >
<!ELEMENT ASSESSMENTS (#PCDATA) >
<!ELEMENT DUES (#PCDATA) >
<!ELEMENT TAXES (#PCDATA) >
<!ELEMENT LENDER (#PCDATA) >
<!ELEMENT EARNEST (#PCDATA) >
<!ELEMENT DIRECTIONS (#PCDATA) >
<!--
***************************************************************
-->
<!--
***************************************************************
-->
<!ELEMENT COMPANY (%NAME;,%ACZ;,%SC;,%PFW;) >
<!ELEMENT AGENT (%NAME;,%ACZ;,%SC;,%PFW;) >
<!ELEMENT OWNER (%NAME;,%ACZ;,%SC;,%PFW;) >
<!ELEMENT TENANT (%NAME;,%ACZ;,%SC;,%PFW;) >
<!ELEMENT COMMISSION (RECIPIENT,AMOUNT) >
<!ELEMENT RECIPIENT (#PCDATA) >
<!ELEMENT AMOUNT (#PCDATA) >
<!ELEMENT OTHER (#PCDATA) >
<!ELEMENT NAME (#PCDATA) >
<!ELEMENT ADDRESS (#PCDATA) >
<!ELEMENT CITY (#PCDATA) >
<!ELEMENT ZIP (#PCDATA) >
<!ELEMENT STATE (#PCDATA) >
<!ELEMENT COUNTRY (#PCDATA) >
<!ELEMENT PHONE (#PCDATA) >
<!ELEMENT FAX (#PCDATA) >
<!ELEMENT WEB (E-MAIL,SITE) >
<!ELEMENT E-MAIL (#PCDATA) >
<!ELEMENT SITE (#PCDATA) >
<!ENTITY lt
"&#60;"> |
|
Cheers, John
Petit
KPMG
XMLfs Team
Office: 970 728
9468
Mobile: 312 961
8956
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC