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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [Fwd: small error in your ebxml manifest proposal]


Chris,

Few comments / suggestions for clarifications:

1. For "any" elements "##other" namespace if fine however, for the "anyAttribute", which is currently limited to the "ebXMLHeader" element only,  I think it needs to be either "##any" or "http://www.ebxml.org/namespaces/messageHeader". This would permit adding additional attributes from the ebXML Header namespace also without having to revise the header. Any reason to permit attributes from other namespaces at all? If not it can be restricted to "http://www.ebxml.org/namespaces/messageHeader" alone.

It may be apparent but I just like to add that, this specification (by definition) permits any number of these (extension) attribute instances in the ebXMLHeader element.

2.  For the "anyAttribute" also I suggest we specify the processContents to be "lax" (default is "strict").

3. Any reason why only ebXMLHeader element needs extension attributes and not other (sub-elements?)

4. There was some debate on this but, how do we plan to convey the "Must Process" / "May Ignore" application processing rule for these "any" elements (especially since they come "other" namespaces?).

Regards, Prasad

christopher ferris wrote:

Note that I have confirmed this with a re-read of the xmlschema-0
spec. I therefore propose that ##other be the value of the namespace
attribute represented in the xsd:any elements.

Cheers,

Chris

christopher ferris wrote:
>
> Wayne,
>
> Thanks for the feedback.
>
> Cheers,
>
> Chris
>
> -------- Original Message --------
> Subject: small error in your ebxml manifest proposal
> Date: Thu, 14 Dec 2000 10:04:26 -0800
> From: "Carr, Wayne" <wayne.carr@intel.com>
> To: "'chris.ferris@east.sun.com'" <chris.ferris@east.sun.com>
> CC: "Adams, Robert" <robert.adams@intel.com>
>
> I'm not on the ebxml mailing list so am not sending this to the list.  If it
> would be useful, feel free to forward it.
>
> You have an error in your proposed extension mechanism, one that is common
> with the use of the "any" element.  XML Schemas must be deterministic.
> For every element in an instance document, the parser must know exactly what
> corresponding part of the schema maps to that instance element.  If you  mix
> up use of the "any" element with the ##any value for the namespace attribute
> (the default) and other elements from your own namespace that can appear
> variable number of times, you create a nondeterministic schema.
>
> <element name="ebXMLHeader" type="ebXMLHeader"/>
> <complexType name='ebXMLHeader'>
> <element ref='Manifest' minOccurs='1'/>
> <element ref='Header' minOccurs='1'/>
> <element ref='RoutingHeader' minOccurs='0' maxOccurs="1"/>
> <any minOccurs='0' maxOccurs='*'/>
> </complexType>
>
> The way you have the above defined, if an instance document contains a
> RoutingHeader element, there is no way to tell if that came from the
> RoutingHeader element in the schema or the following any element which
> can  be anything including the RoutingHearder.  The way to get around this is
> to  put the extension inside an "extension" element.  Another alternative is to
> use ##other as the namespace attribute value rather than ##any.  In an
> extension, there is no reason you'd want to be able to put other
> nonspecified elements from your own namespace.
>
> > **************************
> > Wayne J. Carr
> > wayne.carr@intel.com
> > ICL Web Standards & Architecture
> > Intel Architecture Labs
> > **************************
> >
> >


 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC