[OAI-implementers] namespaces not resolving

Joe Futrelle futrelle at ncsa.uiuc.edu
Fri Nov 9 11:40:03 EST 2007


I want to emphasize these excellent points, because as a semantic web 
developer I see lots of XML processing software balk at RDF/XML data 
because it can't resolve the namespace URI's, which again is 
inappropriate behavior. XML documents don't have follow best practices 
to be valid, and graceful degradation rather than hard fail-fast 
behavior is in my view best practice software design for highly 
distributed document processing systems in which the consumer has no 
control over the producer.

In practical terms I often encounter confusion on the ground about the 
difference between an identifier and a locator, to the point that the 
scheme field of URI's has become overloaded with implicit semantics. At 
which point I chant the semantic web mantra:

Explicit semantics good
Implicit semantics bad

Robin Cover wrote:
> In the OASIS [1] context, it's a hard requirement that HTTP scheme namespace
> URIs resolve to namespace documents.  This rule follows the W3C Web
> Architecture guidance [2], but more the point, specification developers have had
> a lot of experience with namespaces, and concluded on their own that the
> W3C guidance is sound.  A namespace document is a very natural resource type:
> since a namespace document documents a namespace, and
> documentation (as opposed to a 404) is good.  Software that blindly tries to
> follow any HTTP scheme URI (just because it's possible to attempt a
> dereference under DNS+HTTP) is buggy software.  It's best not to confuse
> buggy software design with good Web Architecture design.
> 
> Here are a couple example NS URIs owned by OASIS; they should resolve
> to namespace documents:
> 
> http://docs.oasis-open.org/ws-rx/wsrm/200702
> http://docs.oasis-open.org/wsbpel/2.0/plnktype
> 
> Others:
> 
> DocBook: http://docbook.org/ns/docbook
> GML: http://www.opengis.net/gml
> SVG: http://www.w3.org/2000/svg
> WS-Transfer: http://schemas.xmlsoap.org/ws/2004/09/transfer
> 
> In the more recent W3C practice, NS URIs with the /ns/ path are being used.
> I think it's a good idea because it conveys clearly to a human (and to a
> machine, if you care) that the URI is a namespace URI.
> 
> http://www.w3.org/ns/ws-policy Web Services Policy 1.5 Framework
> http://www.w3.org/ns/wsdl-instance WSDL Instance Namespace
> http://www.w3.org/ns/wsdl/rpc WSDL 2.0 RPC Style Namespace
> http://www.w3.org/ns/wsdl WSDL 2.0 Namespace
> http://www.w3.org/ns/wsdl/soap WSDL 2.0 SOAP Binding Namespace
> http://www.w3.org/ns/wsdl/http WSDL 2.0 HTTP Binding Namespace
> http://www.w3.org/ns/xbl XML Binding Language (XBL)
> http://www.w3.org/ns/rex# Remote Events for XML (REX)
> http://www.w3.org/ns/soap12-mtom-policy MTOM Serialization Policy Assertion
> http://www.w3.org/ns/widgets Widgets 1.0
> http://www.w3.org/ns/xproc XProc: An XML Pipeline Language
> http://www.w3.org/ns/xproc-error XProc Error Namespace
> 
> Cheers,
> 
> Robin Cover
> OASIS, Chief Information Architect
> 
> References: =============
> 
> [1] http://www.oasis-open.org/
> 
> [2] http://www.w3.org/TR/webarch/#namespace-document
>      http://www.w3.org/TR/webarch/#xml-namespaces
>      See also: http://xml.coverpages.org/rddl.html
> 
> 
> On Nov 8, 2007 10:11 PM, Neil Godfrey <godfrey at usq.edu.au> wrote:
>>
>>
>>
>> Not all the name space URL's in the recommended XML schema to represent
>> MARC21 records found at
>> http://www.openarchives.org/OAI/2.0/guidelines-marcxml.htm are resolvable.
>>
>>
>>
>> xmlns= http://www.loc.gov/MARC21/slim goes to a "Page Not Found"
>>
>> xmlns:xsi= http://www.w3.org/2001/XMLSchema-instance goes to a notice
>> forbidding the declarations of attributes in this namespace
>>
>> xsi:schemaLocation= http://www.loc.gov/MARC21/slim goes to a "Page Not
>> Found"
>>
>>
>>
>> Should these resolve? What are the correct values if they should?
>>
>>
>>
>> (I understand the Oxygen xml editor will not validate them.)
>>
>>
>>
>> Thanks,
>>  Neil
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Neil Godfrey
>>
>> Metadata Specialist
>>
>> RUBRIC Project
>>
>> University of Southern Queensland
>>
>>
>>
>> Ph: +61 (0)7 4631 5339
>>
>> Blog: http://metalogger.wordpress.com
>>
>> RUBRIC Website: http://www.rubric.edu.au
>>  USQ Website: http://www.usq.edu.au ________________________________
>>  This email (including any attached files) is confidential and is for the
>> intended recipient(s) only. If you received this email by mistake, please,
>> as a courtesy, tell the sender, then delete this email.
>>
>> The views and opinions are the originator's and do not necessarily reflect
>> those of the University of Southern Queensland. Although all reasonable
>> precautions were taken to ensure that this email contained no viruses at the
>> time it was sent we accept no liability for any losses arising from its
>> receipt.
>>
>> The University of Southern Queensland is a registered provider of education
>> with the Australian Government (CRICOS Institution Code No's. QLD 00244B /
>> NSW 02225M) ________________________________
>>
>> This e-mail (and any attachments) is confidential and may contain personal
>> views which are not the
>> views of English Heritage unless specifically stated. If you have received
>> it in error, please delete it
>> from your system and notify the sender immediately. Do not use, copy or
>> disclose the information in
>> any way nor act in reliance on it. Any information sent to English Heritage
>> may become publicly available.
>> _______________________________________________
>> OAI-implementers mailing list
>> List information, archives, preferences and to unsubscribe:
>> http://www.openarchives.org/mailman/listinfo/oai-implementers
>>
>>
>>
> 
> 
> 

-- 
Joe Futrelle
Digital Library Technologies
NCSA, University of Illinois
http://www.ncsa.uiuc.edu/People/futrelle



More information about the OAI-implementers mailing list