xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Dierken <m...@DataChannel.com>
Subject RE: Why AF have nothing to do with my proposal
Date Thu, 23 Dec 1999 01:21:16 GMT
Here is some more information that I've gleaned from talking w/ Eliot
Kimber:

===================

Mike Dierken wrote:
> 
> "The architecture mechanism uses attributes to define the mapping, so you
> can have any
> number you care to, in addition to the element type name itself."
> 
> Could you give a simplistic XML snippet showing this?
> 
> For example: <folder rio-type='catalog' xyz-type='productlist'
> abc-type='stuff' />

Here is the starting document. It is mapped to three architectures. The
"IS10744 arch" PIs formally define the mapping, binding the local
architecture name (the value of the "name" attribute) to the
documentation for the architecture (system-id) and the XML DTD for the
architecture (dtd-system-id). The "arch-doc-form" says what element type
in the architecture the root element of the document maps to--this
ensures that each view creates a proper document with a single root
element:

<?xml version="1.0"?>
<?IS10744 arch 
  name="rio-type"
  system-id="http://datachannel.com/typedefs/rio-types.xml"
 
dtd-system-id="http://private.site.datachannel.com/ourdtds/rio-types.dtd"
  arch-doc-form="repository"
?>
<?IS10744 arch 
  name="xyz-type"
  system-id="http://xyz.com/typedefs/xyz-types.xml"
  dtd-system-id="http://www.xml.org/registry/xyz-types.dtd"
  arch-doc-form="product-info"
?>
<?IS10744 arch 
  name="abc-type"
  system-id="http://abc.com/typedefs/abc-types.xml"
  dtd-system-id="http://www.xml.org/registry/abc-types.dtd"
  arch-doc-form="stuff-set"  
?>

<mydoc>
 <list-of-stuff
   rio-type="catalog"
   xyz-type="productlist"
   abc-type="stuff">
  <stuff-item xyz-type="product">A car</stuff-item>
 </list-of-stuff>
</mydoc>

Note that the architecture use declaration PIs are providing information
similar to that provided by a namespace declaration, but are giving
more. In a namespace declaration you simply bind a local prefix to a
namespace URI. Here, we're binding a local architecture name to the URI
for the architecture as a whole, as well as binding to a formal
definition of the syntactic rules for the architecture, which includes
the set of element type and attribute names valid in that architecture.
In addition, the architecture standard says that the URI should be
resolvable to the documentation for the architecture (although there
should be no processing failure if the architecture URI is not
resolvable).

Thus, architectures provide the same level of name globalization that
namespaces do while providing additional semantic and syntactic bindings
that namespaces cannot provide (because the namespace spec does not
define a mechanism for doing it).

In this sense, architectures are a proper superset of namespaces. There
is no *syntactic* conflict between the use of namespaces and
architectures so both can be used together.

For each architectural view of the document we can generate
"architectural instances" that reflect the mapping for that view (you
can also imagine the corresponding DOM for each view):

Rio architecture:

<?xml version="1.0"?>
<repository>
 <folder>a car</folder>
</repository>

Note that the "stuff-item" element isn't reflected because it isn't
mapped in this view, but the data content is, because by default data
characters map to data characters if the architecture allows them (which
we presume the Rio architecture does in this case).

XYZ architecture:

<?xml version="1.0"?>
<product-info>
 <productlist>
  <product>A car</product>
 </productlist>
</product-info>

In this view, the "stuff-item" element is mapped, so it is reflected in
the view.

ABC architecture:

<?xml version="1.0"?>
<stuff-set>
 <stuff>A car</stuff>
</stuff-set>

In the abstract processing model for architectures, all the views are
available all the time and there are two-way pointers between the base
document's DOM and the DOM for each view, so you can easily navigate
between them. Thus, if I'm processing the "list-of-stuff" node in the
base document's DOM, I can as to see all of its architectural mappings.
This lets me ask questions like "find all elements that are 'stuff' in
the ABC view" and get an answer. I can also do things like "if node has
a base type of 'list-of-stuff' and is both a Rio 'folder' and ABC
'stuff', then do X, otherwise do Y".

One problem with implementing this model in a DOM context is that the
DOM currently does not define a way to establish relationships between
nodes in different DOMs (as far as I know). But obviously it's not a
hard thing to do or imagine (although there are some tricky
object-management-in-memory issues on the implementation side,
especially if you have read-write DOMs where garbage collection type
issues are exposed).

The different views cannot directly interfere with each other because
there is no direct dependency between one view and any of the others.
The only requirement is that the base document be mappable to all the
views (which is a function of the design of the base
document, not the architectures to which it is mapped).

Cheers,

E.

Mime
View raw message