Re: Issue 225: accommodating non-XML data models (proposal)

I think that I'm mostly in favor of this, with some notes and some
reservations.

On Mon, 14 Jun 2004 17:05:40 -0700
Mark Nottingham <mark.nottingham@bea.com> wrote:
> Similarly, the Internet Media Type system is far more prevalent than  
> XML, and it's easy to imagine cases where people would want to describe 
> non-XML Web services and sites using WSDL. Why should they be forced  
> into modelling their data as an Infoset?

A good example; we know that demand exists for this.

> The only changes that I see as necessary to allow alternate data models 
> are:
> 
> 1) Section 2.1.1 - remove this sentence: "They define the [local name], 

[snip]

> 2) Table 2-1 - change the mapping of {element declarations} from:
[snip]
> """ The content declaration components corresponding to the content  
> declarations defined as descendants of the types element information  
> item, if any, plus any imported content definitions."""

I want a definition of "content declaration".  Maybe, instead of simply
removing the definition (bullet point) in item 1, replace it with a
definition of "content declaration"?

> 3) Section 3 - remove this sentence: "At the abstract level, the  

[snip]

> 
> 4) Throughout - Change instances of "element declaration" to "content  
> declaration", the {element} property to {content}, and instances of the 
> "element" Attribute Information Item to "content".

Hmm.  13 instances of "{element}", 27 of "element declaration".  Harder to
count instances of "element" attribute information item.  But this AII is
associated with XML Schema, is it not?  Do we *really* need to change it? 
Again?  The element AII appears in faults and in messages.  In messages,
it is clearly marked as belonging to W3C XML Schema definitions.  It
doesn't seem to be as clear in the discussion of its use in faults, but
the same principles ought to apply, it seems to me.

I have no problems with using an "element" AII to generate the value of
the {content} property.  I am reluctant to change the name of the
"element" AII.  I would rather see, if needed, a clarification that it is
defined with reference to W3C XML Schema, and MAY be used by other
infoset-compatible type systems, but MUST NOT be used by non-infoset data
models (which may define their own corresponding AIIs).

> 5) In the Bindings section, note that bindings should enumerate the  
> data models that they can serialise into concrete messages.

More than just there, please.  This introduces, conceptually, a property,
(for each message?  is aggregation possible somehow?), {data model}.  Each
{content declaration} is associated with some {data model}, implicitly
establishing that property.  The association of a {content declaration}
with the {content} of a message or fault also establishes the association
with the {data model} property.  Each "type system" has a {data model} (or
is this true?), and so long as each defines that property explicitly,
bindings can be checked for conformance explicitly.

I did some snips above.  There's a bit more removal than replacement going
on here.  I've suggested that the definition of {content declaration}
should replace the definition of {element declaration} rather than simply
removing that information.  My concern is that by removing specific
language, we are potentially opening ourselves to ambiguities that are
not, at the moment, foreseen.  That's part of the reason for suggesting an
explicit {data model} property.  It limits the meaning of "content" to
"content defined in some language that describes a particular data model",
and I think we need at least that much.

Amy!
-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Tuesday, 15 June 2004 11:34:21 UTC