[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Schema-Specification normative preference wasRE:[ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace
Duane: In message-header-2_0.xsd, we include the following import clauses: <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xmldsi g-core-schema.xsd" /> <import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/xlink. xsd" /> <import namespace="http://schemas.xmlsoap.org/soap/envelope/" schemaLocation="http://www.oasis-open.org/committees/ebxml-msg/schema/envelo pe.xsd" /> <import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd" /> These import clauses are necessary because attributes and elements defined in these foreign namespaces are actually referenced within the message header schema (e.g., soap:mustUnderstand, xlink:href, ds:Signautre, xml:lang, etc). I don't think the message header schema would be valid without the import clauses. The import construct is used in the schema definition, not in an instance document. I am a little confused when you wrote: > > 1. In an instance document, the attribute xsi:schemaLocation provides hints > > from the author to a processor regarding the location of schema documents. > > The author warrants that these schema documents are relevant to checking the > > validity of the document content, on a namespace by namespace basis. For > > example, we can indicate the location of the Report schema to a processor of > > the Quarterly Report: > <SNIP>/..... > > My interpretation of the above: This refers to importing definitions in > order to perform a validating parse on an "instance document" - as the > example states. If someone wishes to check the validity of a namespace > qualified element to see if its' content matches (ie - datatyping > constaints or content model), then they may have to resolve the > schemalocation. > > What I am asking is "Is the requirement importing definitions OR is it > to avoid naming conflicts?" -Arvola ----- Original Message ----- From: "Duane Nickull" <duane@xmlglobal.com> To: "Arvola Chan" <arvola@tibco.com> Cc: "Dale Moberg" <dmoberg@cyclonecommerce.com>; "David Fischer" <david@drummondgroup.com>; "Christopher Ferris" <chris.ferris@sun.com>; "Doug Bunting" <dougb62@yahoo.com>; "ebXML Messaging" <ebxml-msg@lists.oasis-open.org> Sent: Monday, February 18, 2002 4:59 PM Subject: Re: Schema-Specification normative preference wasRE: [ebxml-msg]Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace > Comments inline: > > Arvola Chan wrote: > > > > Duane: > > > > The reason why the ebxml-msg TC has to define its own namespace is because > > the ebXML message header elements are defined as extensions to the SOAP > > Header and SOAP body elements. SOAP requires extension elements to be > > namespace qualified. > >>>>>>> > > Arvola: > > Yes - I am very aware of namespaces themselves. My question revolved > around a comment that someone made to this thread complaining that they > could not import the definitions from the namespace schemaLocation > target. I wondered why it would ever be a requirement to import the > actual definitions (the specification says you must be able to do so via > the schemalocation attribute as you quote below.). If it is a > requirement, then I personally was curious of the driver for that > requirement. > > It seems like it may not be a formal requirement and that perhaps we are > simply using the namespace values to avoid conflicts (since you cite the > SOAP example as the driver). If this is true, then there is no > problem. > > > > > The schemaLocation attributes in the schema and in instance documents only > > serve as hints. Schema processors are not required to use these hints. The > > application that invokes a schema processor can direct the latter not to > > dereference the value specified for the schemaLocation attribute and instead > > use some cached version of the schema. > >>>>> > > Local caching still requires you resolve it at least once. > > > The following is an excerpt from http://www.w3.org/TR/xmlschema-0/ > > > > " > > 5.6 schemaLocation > > XML Schema uses the schemaLocation and xsi:schemaLocation attributes in > > three circumstances. > > > > 1. In an instance document, the attribute xsi:schemaLocation provides hints > > from the author to a processor regarding the location of schema documents. > > The author warrants that these schema documents are relevant to checking the > > validity of the document content, on a namespace by namespace basis. For > > example, we can indicate the location of the Report schema to a processor of > > the Quarterly Report: > <SNIP>/..... > > My interpretation of the above: This refers to importing definitions in > order to perform a validating parse on an "instance document" - as the > example states. If someone wishes to check the validity of a namespace > qualified element to see if its' content matches (ie - datatyping > constaints or content model), then they may have to resolve the > schemalocation. > > What I am asking is "Is the requirement importing definitions OR is it > to avoid naming conflicts?" > > If anyone knows the answer, can they please state the answer and if it > is definition importing as a strict requirement, please state why. > > Thanks > > Duane Nickull > -- > CTO, XML Global Technologies > **************************** > Transformation - http://www.xmlglobal.com/prod/foundation/ > ebXML Central - http://www.xmlglobal.com/prod/central/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC