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


Help: OASIS Mailing Lists Help | MarkMail Help

ws-brsp message

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

Subject: 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


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

  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 <JDurand@us.fujitsu.com> 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.



From: ws-brsp@lists.oasis-open.org [mailto:ws-brsp@lists.oasis-open.org] On Behalf Of Chet Ensign
Sent: Monday, August 26, 2013 11:29 AM
To: Jacques Durand; ws-brsp@lists.oasis-open.org
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: 



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 Ensign
Director of Standards Development and TC Administration 
OASIS: Advancing open standards for the information society

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: robin@oasis-open.org
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

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