OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Architectural Forms and XAF

[ Lists Home | Date Index | Thread Index ]
  • From: "W. Eliot Kimber" <eliot@isogen.com>
  • To: xml-dev <xml-dev@xml.org>
  • Date: Sun, 05 Mar 2000 18:49:04 -0600

Steven Rowe wrote:
> 
> "W. Eliot Kimber" wrote:

> > improved. It was (and is) my hope that XML Schema would do AFs better
> > than we can do them now for the very reason that XML Schema is not bound
> > by the same restrictions we were.
> 
> Eliot,
> 
> What would you like to be able to do with XML-Schema (but can't) that
> you can now do with AFs?  Is the problem space targetted by XML-Schema
> a superset (at least an improper one) of that which is solved by AFs?

It's not a superset/subset issue. It's a matter of AFs satisfying a set
of requirements that XML Schema today does not satisfy (or even attempt
to address).

The key thing that architectures let you do is map from a *specialized*
set of types to a *generalized* set of types where the generalized types
are defined and managed separately from the specialized types. In
addition, the same specialized type must be mappable to multiple general
types (I am both a husband and an employee). This is different from the
simple specialization that XML Schema currently provides, which is
simple derivation of one type from another within the same set of types
(a single schema). It is also different from importing a set of types
into a name space in order to use them locally (what is usually referred
to as modularization).  For XML Schema to satisfy the AF requirements, I
think it needs to do the following:

1. Provide a syntax for binding types in one schema to types in another
schema to define "is-a" relationships. The current AF mechanism does
this today with attributes. It would probably be cleaner to have a
separate declaration type for asserting this mapping at the schema
level. [Note that the current AF mechanism, because it is attribute
based, allows instances of a given element type to have different
mappings for the same architecture, although this feature is rarely, if
ever, used in my experience (I have certainly never used it with the
expectation that document authors would set the architectural mapping
themselves and have never needed this in order to solve any problems
I've had).]

2. Provide a facility for remapping local names to architectural names
(the "architectural naming attribute" in the current AF mechanism).
Again, this can be part of a specialized mapping declaration.

3. Provide a way to formally declare that one document/schema is derived
from an architecture (remembering that the architecture is more than
just a schema declaration, it is also the supporting documentation that
describes the semantics of the types defined by the architecture).

This would provide a cleaner syntax that is more direct and probably
enable the ability to do more things with the mapping, such as mapping
two things to one, one to two, structural reordering, and the like
(although I haven't thought about this too much).

Cheers,

Eliot

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS