[regrep] v3 Issue: "flat" vs "nested" XML representations

[Len Gallagher <LGallagher@nist.gov>]

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
**************************************************************