RE: Identifying markup using namespaces versus using data (was:4 approac

["Cox, Bruce" <Bruce.Cox@USPTO.GOV>]

It looks good to me, Roger, but I think Ken's comment at the end isn't
quite the whole story.  Sometimes you might want to style a list
differently based on its content type.  Sometimes you want to
decimal-align, sometimes you don't, for example.  Some processing might
be keyed to the content, which I suppose can be done using the value of
Identifier on the one hand, or the element names or namespace on the
other.

Is one or the other approach better for content-specific processing,
where it is needed?  

Or have I missed the point?

Bruce B Cox
Manager, Standards Development Division
OCIO/SDMG
571-272-9004


-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org] 
Sent: Thursday, February 19, 2009 2:27 PM
To: 'xml-dev@lists.xml.org'
Subject: Identifying markup using namespaces versus using data (was: 4
approaches to structure lists, plus an analysis of each approach)


Hi Folks

One way of identifying an XML building block (data component) is by
namespace. For example, this list component is identified by the
namespace http://week.days.org

   <DaysOfTheWeek xmlns="http://week.days.org";>
       <Day>Sunday</Day>
       <Day>Monday</Day>
       <Day>Tuesday</Day>
       <Day>Wednesday</Day>
       <Day>Thursday</Day>
       <Day>Friday</Day>
       <Day>Saturday</Day>
   </DaysOfTheWeek>

This list is identified by the namespace http://meetings.org

   <Meetings xmlns="http://meetings.org";>
       <Meeting>Dentist</Meeting>
       <Meeting>Doctor</Meeting>
       <Meeting>Boss</Meeting>
   </Meetings>

Applications can be built that are namespace-aware.

Different data components can be mashed together into a single document
and still be extracted and processed individually because each is in a
namespace.


There is an alternate way of identifying an XML building block (data
component): by embedding an identifier within the document, as data. The
weekday list could be expressed like this:

    <List>
        <Identifier>http://week.days.org</Identifier>
        <li>Sunday</li>
        <li>Monday</li>
        <li>Tuesday</li>
        <li>Wednesday</li>
        <li>Thursday</li>
        <li>Friday</li>
        <li>Saturday</li>
    </List>

And the meetings list could be expressed like this:

    <List>
        <Identifier>http://meetings.org</Identifier>
        <li>Dentist</li>
        <li>Doctor</li>
        <li>Boss</li>
    </List>

Things to note:

1. Namespaces are not being used. (I formatted the identifier as a
namespace, but I didn't have to do that)

2. The list is identified by the content of <Identifier>

3. The same XML vocabulary is used for both lists. (In fact, the same
XML vocabulary is used for all lists)

The two lists can be brought together into a single document and still
be processed individually. Applications partition the document based on
the value in <Identifier>


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
        ANALYSIS
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The namespace approach has the benefit of being widely adopted. Most XML
tools, parsers, and technologies are based on namespaces. For example,
NVDL is entirely based on using namespaces to partition a compound
document; an XSLT processor processes a document based on the XSLT
namespace.

Ken nicely summarizes the advantages of the second approach:

> [because the same XML vocabulary is used for all lists it] makes all 
> list-processing algorithms and code independent of the content, 
> allowing one to leverage a single investment in software and access 
> all code lists.


Do you agree with this analysis? What else would you add?

/Roger