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>