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

On Jun 15, 2004, at 8:20 AM, Amelia A Lewis wrote:
>> """ 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"?

Agreed.

>> 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 don't think this is critical, but have always found the element AII 
confusingly named; content seems much more intuitive, even if we were 
to restrict data models to the Infoset.

> 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).

Interesting; so you're suggesting that the element AII populates the 
content property when present, but when an alternate data model is in 
use, another attribute might populate the content property?


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

This seems reasonable.

Cheers,

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Tuesday, 15 June 2004 14:43:34 UTC