Re: [ws-brsp] Two problems that need to be fixed for the WS-BRSP machine readable files

Thanks, Jacques.  And again I regret that I did not keep track of the spec
so as to catch the anomaly sooner.

I neglected to provide the URI reference for the explanation as to why

"real" (tangible, aka "information resources") assets are not located

or stored physically in the file system beneath the fictitious /ns/... here it is

http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#ns-pathElementReserved

As Paul suggested, it should be straight-forward to locate the XSD schema

in a real directory as a child to the main prose spec document, for

example, and use the path to that XSD file in/as the value of the

(pseudo) attribute "schemaLocation".  The main thing is to get the

XML namespace name itself correct (no /ws-i/ component for a

TC-shortName) per the Naming Directives and per our current server

configs that support URI rewrites.

Paul: let me know if I've overlooked anything more subtle: the

fixup seems simple enough.

- Robin

================ Earlier:

 Secondly, one of your resources (or maybe more than one)

presents a value for a schemaLocation (pseudo) attribute

as:

  http://docs.oasis-open.org/ns/ws-i/ws-brsp/Profile-TAs/201305 Profile-TAs.xsd

That will not work, for at least two reasons:

a) the illegal SPACE in the filename: we never install resources in the

    OASIS Library with SPACE in the directory/file name [SOP]

b) the path portion /ns/ws-i/ws-brsp/Profile-TAs/ does not

   exist because the /ns/ URI component is just

   imaginary: no user file or directory is ever

   stored literally under the /ns/ path portion,

   which exists just for namespace management

The explanation for "b)" immediately above is presented

also in the Naming Directives:

  "The pattern specified above for HTTP scheme URIs

   uses the /ns/ path element in a syntax reserved for

   identifying non-information resources only.

   Therefore, no (file-system) regular files,

   directories/folders, or symbolic links matching

   information resources may make use of these URI

   strings for resource identification."

BTW: the use of a /ns/ element just for namespace

name construction is not an OASIS invention: it's

used widely in other SSOs/SDOs.

On Wed, Aug 28, 2013 at 8:38 PM, Jacques Durand <> wrote:

Thanks Chet:

We’ll look into this with our schema editor, Tom.

I think we should be able to fix and submit new CSDs by electronic ballot early September.

-jacques

 

From:  [mailto:] On Behalf Of Chet Ensign

Sent: Monday, August 26, 2013 11:29 AM
To: Jacques Durand; 
Cc: Paul Knight; Robin Cover
Subject: [ws-brsp] Two problems that need to be fixed for the WS-BRSP machine readable files

 

Jacques & members of the WS-BRSP TC, 

 

In processing the requests for Committee Spec Drafts and public reviews for WS-BRSP, I encountered two problems in the associated machine artifact files that I need the TC to fix. These problems occur in the associated machine readable files for Reliable Secure Profile v1.0, Basic Profile v1.2 and Basic Profile v2.0.  

 

1. The OASIS namespace coined does not follow the namespace rules in the Naming Directives (http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#xml-namespaces). Specifically, the namespace in the schemas and other related files is http://docs.oasis-open.org/ns/ws-i/ws-brsp/Profile-TAs/201305. The legal form is http://docs.oasis-open.org/[tc-shortname]/ns/xxxx where xxxx is a character string picked by the TC.

 

2. There is at least one instance (in TestAssertionsBasicProfile-1.2.xml) of an element using a blank space in what appears to be a file name ( <profile… xsi:schemaLocation="http://docs.oasis-open.org/ns/ws-i/ws-brsp/Profile-TAs/201305 Profile-TAs.xsd"). Per the Naming Directives, filenames cannot contain blank spaces. 

 

Note that there was also a file submitted with space characters in the name  - Test Assertions Reliable Secure Profile - Version 1.0.htm. I removed those blank spaces from the filename. 

 

Here is what I need the TC to do to remediate this: 

 

1. The Naming Directives state that a namespace must use the pattern: 

 

http://docs.oasis-open.org/[tc-shortname]/ns/xxxx 

 

where xxxx can be a string picked by the TC. Based on the namespace submitted, I believe that http://docs.oasis-open.org/ws-brsp/ns/Profile-TAs-201305 would be acceptable to the TC. If it is, then please revise all namespaces where they occur in the computer language files to reflect this pattern. 

 

2. Remove the blank space from xsi:schemaLocation="http://docs.oasis-open.org/ns/ws-i/ws-brsp/Profile-TAs/201305 Profile-TAs.xsd"any place it occurs in the files. It can be deleted or replaced with a hyphen. 

 

3. Once you have these fixed, email the revised files to me so that I can replace them in the CSDs and CSPRDs. 

 

Please let me know if you have any questions. 

/chet 
----------------
Chet Ensign
Director of Standards Development and TC Administration 

OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298

Mobile: +1 201-341-1393 

 

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html 

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen

Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open

-- 
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: 

Staff bio: http://www.oasis-open.org/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/

Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783