Re: [ebxml-msg] Minor discrepancy between spec and schema

[Doug Bunting <dougb62@yahoo.com>]

I would suggest a slight change in the use of attributes from foreign
namespaces when restoring this option to our schema.  A little history...

The <anyAttribute/> element was part of the MessageHeader and Manifest
definition in the most recent schema that included it
(draft-msg-header-04.xsd).  That was probably a mistake and it certainly led
to my confusion and incorrect suggestion to remove these options.

Why was I confused?  Well, the only reason I'd heard for these
<anyAttribute/> options was in support of xsi:schemaLocation on the two
elements.  That sounded as if it could have been actually the reason since
these elements "feel like" they were the only top-level SOAP extensions at
some point in time.  (I'm not sure they ever were the only SOAP modules we
had.)  It's a lousy reason because it uses a shotgun to swat a fly.  Using
this reasoning as a basis, I proposed removing the two very inconsistent
inclusions of foreign attributes rather than adding seven more such options
(for the other SOAP modules).  I also discarded specifically including
xsi:schemaLocation in all of our modules because it's much simpler to put
that information in the parent soap:Envelope, soap:Header and soap:Body
elements.

In thinking and talking more about these foreign attribute options, I've
come to think they're a very useful way to add attributes defined in other
schema to the generally useful Manifest and Reference elements.   I was
recently reminded of the long discussion of using ds:Reference directly
rather than defining our own work-alike element.  The problem arose because
ds:Reference doesn't support a simple extension mechanism through allowing
foreign attributes.  The two most generally useful elements in our
specification are Manifest and Reference.  I propose we include
<anyAttribute/> in their definitions.  This would add the text Arvola
highlighted to those elements and modify the 2.0 schema.

So, why was <anyAttribute/> on MessageHeader a mistake?  (It wasn't a
mistake to have it on the Manifest element.)  It's not nearly as useful
beyond the boundaries we've defined but it was there in 1.0.  I don't care
very much whether or not we restore this particular option.

thanx,
    doug

----- Original Message -----
From: "David Fischer" <david@drummondgroup.com>
To: "David Fischer" <david@drummondgroup.com>; "Christopher Ferris"
<chris.ferris@sun.com>; "Arvola Chan" <arvola@tibco.com>
Cc: <ebxml-msg@lists.oasis-open.org>
Sent: Wednesday, 16 January 2002 06:30
Subject: RE: [ebxml-msg] Minor discrepancy between spec and schema


Sorry, we were talking about foreign attributes.  This too was added
somewhere
before v0.9.

David.

-----Original Message-----
From: David Fischer [mailto:david@drummondgroup.com]
Sent: Wednesday, January 16, 2002 8:25 AM
To: Christopher Ferris; Arvola Chan
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Minor discrepancy between spec and schema

Yes, I too think we need to modify the schema.  This wildcard has been in
the
spec since before v0.9 (it was added somewhere after v0.8).  I don't
remember
why it is there but I think we can't delete without discussion.  Until then,
we
should fix the schema.

David.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Tuesday, January 15, 2002 4:21 PM
To: Arvola Chan
Cc: David Fischer; ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Minor discrepancy between spec and schema

David,

attributes and elements aren't necessarily equivalent.
I would suggest that the schema be modified to be
consistent with the spec text. It may be important that
a foriegn attribute be added.

Cheers,

Chris

Arvola Chan wrote:

> The following is an excerpt from Section 3.2.1:
>
> The Reference element has the following attribute content in addition to
> the element content described above:
>
> ·          id - an XML ID for the Reference element,
>
> ·          xlink:type - this attribute defines the element as being an
> XLINK simple link. It has a fixed value of 'simple',
>
> ·          xlink:href - this REQUIRED attribute has a value that is the
> URI of the payload object referenced. It SHALL conform to the XLINK
> [XLINK] specification criteria for a simple link.
>
> ·          xlink:role - this attribute identifies some resource that
> describes the payload object or its purpose. If present, then it SHALL
> have a value that is a valid URI in accordance with the [XLINK]
> specification,
>
> ·          Any other namespace-qualified attribute MAY be present. A
> Receiving MSH MAY choose to ignore any foreign namespace attributes
> other than those defined above.
>
> The bullet in red is inconsistent with the schema (which does not have
> the #wildcard attribute). Since the Reference element already has a
> #wildcard sub-element, and we have agreed to uniformly add #wildcard
> sub-element to most key elements to provide extensibility, I would
> recommend striking out the above bullet in red.
>
> Regards,
> -Arvola
>
>
>




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>