one of web services inherited in current job contains wsdl schema following namespace definition:
<xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mns="http://my.example.com/sumproj/msgs.xsd" xmlns:tns="http://my.example.com/sumproj" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetnamespace="http://my.example.com/sumproj/msgs.xsd" elementformdefault="qualified"> all of external urls listed above can accessed through web browser, internal ones (my.example.com domain) produce "not found" error:
not found
the requested url /sumproj/msgs.xsd not found on server.
since person ask why things implemented way has left, wondering whether bug or feature:
has authoring developer intended place namespace xsd on http://my.example.com server , didn't implementing it?
or type of security feature in url accessible web service through config xml, defining url virtual when access localhost or similar?
if latter, how work , where can learn more it?
(note: example.com above used illustration, can't disclose employer's internal url)
has authoring developer intended place namespace xsd on http://my.example.com server , didn't implementing it?
that's possible, not certain; without reading developer's mind no firm answer possible. rational developer might either way -- if many people including me it's better practice , more rational put namespace documentation (possibly in form of schema document, possibly in form of rddl document, possibly in form) @ namespace uri.
or type of security feature in url accessible web service through config xml, defining url virtual when access localhost or similar?
not impossible, not design technique seems documented. (at least, there's @ least 1 xml geek who's never heard suggested.) guess answer is: not original author's intent.
can point me authoritative source can read this?
the authoritative source xml namespaces documents "namespaces in xml 1.0 (third edition)" , "namespaces in xml 1.1 (second edition)", edited tim bray et al. , published world wide web consortium in 2009 , 2006, respectively.
it's difficult prove negative concisely, examination of spec should make clear imposes no requirement uris used namespace names should dereferenceable. section 2.1 says "an xml namespace identified uri reference [rfc3986]" nothing in spec requires namespace names dereferenced. section 2.3 defines process of namespace-name matching test string identity , points out means equivalent forms of same uri (e.g. http://www.example.org/wine , http://www.example.org/wine) not count equal purpose of namespace-name matching. make no sense @ if namespace processors required dereference namespace names.
the w3c technical architecture group (tag) discusses complex of questions higher-level point of view in document architecture of world wide web, volume one. see in particular
- section 3.5 (which enunciates principle "reference not imply dereference": "an application developer or specification author should not require networked retrieval of representations each time referenced."
- section 4.5.3 on xml namespaces
- section 4.5.4 on namespace documents (which tag recommends)
see this related question (and answer it).
if name space url point resource, imply wsdl schema must consult @ runtime?
no. wsdl can impose rules on use of namespace names in wsdl documents, document fragment quote xsd schema document. xsd spec not require namespace names dereferenced (although suggest 1 possible strategy locating xsd schema documents use in validation episode).
if answer no, can consult @ runtime? or human reading?
it not forbidden processors dereference namespace name, authorities discourage it. when deployed software dereferences namespace names every time runs, or every time reads xml document, result can excessive , unnecessary network traffic. w3c has been suffering under such unnecessary traffic years , serves schemas @ artificially slow rates in order persuade users complain software vendors. (see ted guild's blog post of 2008 details.)
Comments
Post a Comment