[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [regrep] v3 Issue: "flat" vs "nested" XML representations
Registry TC, It is my hope that our upcoming F2F (Oct 31 - Nov 2) will find some time to discuss issues that do not require an immediate solution. It would be good if we could get a "sense of the group" on some of these issues so that those thinking of writing proposals to address future functionality will have some feeling about the likely success of their ideas. ISSUE Should the XML representations in our Registry Services specification support "nested" XML representations of RIM classes in addition to their current support for "flat" XML representations of RIM classes. DISCUSSION In existing ebRS there is an XML Element definition for nearly every class defined in ebRIM. I will call these "flat" representations because they are mostly XML elements that have only attributes defined for them. There is very little use of "nested" XML elements. Instead of nesting, our current XML definitions make extensive use of XML "ID" and "IDREF" capabilities to link together related XML Elements. There is nothing wrong with this -- but it does make it much more difficult to leverage XML tools that work best with nested representations. For example, our documents state that we intend to take future advantage of XPath and XQuery in Registry Services, yet both XPath and XQuery require the existence of an XML document (at least a virtual one!) before their definitions make sense. Since our XML representations are essentially "flat", there is no virtual "nested" XML document to apply these advanced XML tools against. I see value for supporting BOTH "nested" and "flat" XML representations in our specifications. When submitting a new RegistryEntry instance to the Registry, it would be convenient if all of its Association and Classification instances, as well as all of its ExternalLink, ExternalIdentifier, and Slot instances, could be submitted as part of the same nested document. As things stand now, they must be submitted as independent instances, then linked together with somewhat artificial "ID" and "IDREF" declarations. Similarly on retrieval. In our existing specifications, if a Client asks for all of the nodes of a specific classification scheme taxonomy, it gets back a set of ClassificationNode instances, each with an optional "parent" attribute to point to a potential parent node. This means that the Client software must re-construct the natural hierarchy of the taxonomy by chasing down all of the "parent" IDREF's and the ID's that they reference. It would be helpful if the Client could request that the nodes be returned in a nested format, as an XML document, so that it could use its own XML tools to manipulate the taxonomy directly, without having to construct the implied document from the IDREF's. For example, it would be very helpful for both Input and Retrieval, if all of the nodes of a classification scheme taxonomy could be collected together, WITHOUT REQUIRED USE OF IDREF's and ID's, as an XML document that validates to the following DTD: <!ELEMENT ClassificationTaxonomy ( ClassificationNodeNested+ )> <!ELEMENT ClassificationNodeNested ( ClassificationNodeItem, ClassificationNodeNested* )> <!ELEMENT ClassificationNodeItem ( Description? )> <!ATTLIST ClassificationNodeItem name CDATA #IMPLIED code CDATA #REQUIRED > The "name" and "code" attributes of ClassificationNodeItem are the same as those attributes in the existing ClassificationNode element of ebRS, but the item element is no longer required to carry along superfluous "id" and "parent" attributes. Instead, those attributes are "implied" by the structure of the XML document. CONCLUSION I am NOT proposing that we replace the existing "flat" XML representations with "nested" ones. I see significant value in retaining the "flat" representations, especially for Registries that are implemented using relational database systems. However, I see no reason why our specifications can't leverage the powerful XML tools (e.g. XPath, XQuery) for dealing with "nested" structures by providing optional "nested" definitions for important ebRIM classes, especially RegistryEntry, Package, ClassificationScheme, etc. -- Len *********************************************************** Len Gallagher LGallagher@nist.gov NIST Work: 301-975-3251 Bldg 820 Room 562 Home: 301-424-1928 Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213 **************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC