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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

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


Subject: Comments on WSRF-RMD


Folks,

At long last, I found time to go through this. Here are my comments in 
four categories schema, questions, typos, and issues. I am refering to 
version wsrf-ws_resource_metadata_descriptor-1.0-spec-wd-07.doc

Schema:
=======

The following is thanks to M. Dresher who validated the schema for me.

Line 1028: Change
"<xsd:import namespace="http://docs.oasis-open.org/wsrf/rp-2"; 
schemaLocation="http://docs.oasis-open.org/wsrf/rp-2"; />

to

"<xsd:import namespace="http://docs.oasis-open.org/wsrf/rp-2"; 
schemaLocation="http://docs.oasis-open.org/wsrf/rp-2.xsd"; />

Lines 1066 - 1067, 1076 - 1080, 1112 - 1114, 1123 - 1127, 1152 - 1159, 
1168 - 1177, 1213 - 1214, 1219 - 1224, 1236 - 1237, 1242 - 1247, 1261 - 
1262, 1267 - 1272, 1285 - 1286, 1292 - 1296: We know from other 
specifications that if some one wants to extend the RMD schema, a 
likely possibility in addition to defining elements for the {any} 
component, the {any} component must come first to to avoid non unique 
particle attribute errors. Note that the pseudo schema in the document 
will also need modification.


Questions:
==========

Line 589: Do we know that all simple types are ordered sets?


Typos:
======

Line 130: The "MAY" should be "may", as this is a non-normative part of 
the document.

Line 322: 455 should be 45.

Line 330: Missing Non-Normative reference to WSDL 2.0.

Line 385: 94 should be 93.

Line 427: Change "RDM file" to "Resource Metadata Descriptor document".

Line 429: Relationship between MD and ptotType should be just 
"<<describes>>"

Line 429: InitialValues should be ValidValueRange.

Line 467: Section ref 7.

Lines 477, 479, 480: Change "must" to "MUST".

Line 500: Need Reference [WSDL 2.0]

Line 543: Ref section 8.

Line 559: Ref section 8.

Lines 570 - 571: The ValidValues and ValidValueRange definition uses 
just "or". However, the non-normative pseudo schema uses choice. The 
language should be more precise.

Line 604: The 'must' must be 'MUST'.

Line 653: Ref section 8.3

Line 655: Ref section 8.5

Line 845: Character extensibility was replaced with documentation 
elements. Delete this line.

Line 863: Namespace restriction text is missing from this definition.

Line 865: Character extensibility is not needed here. Delete this line.

Lines 927 - 932: Cut and Paste error. A different paragraph is needed 
here.

Lines 945 - 947: The AppNotes reference should by Non-normative.


Issues:
=======

Line 469: These mapping sections seem excessively repetitive. They add 
no additional information and only create an opportunity for additional 
errors.
Recommendation: Delete sections 6.1, 7.1, 8.1, and 8.4.1. Note if this 
recommendation is not accepted, new sections will be needed for mapping 
ValidValues (Section 8.3) and StaticValues (Section 8.5).

Line 564: The 'path' definition implies that it may address the 
resource property, some element, or an attribute somewhere in the 
document. This creates a tension with other parts of the spec that 
imply the only the resource property is addressed.
Recommendation: Reword this definition to specify addressing only the 
resource property. Also, in line 738 the phrase "(or child element 
thereof)" needs to be deleted.

Line 564: Depending on the resolution to the above, the question 
arises, "Is path the right term, if we are only referring to resource 
properties?"
Recommendation: Change 'path' to 'qname'.

Lines 697, 705 - 708, 755, 785 - 787, 822, 831 - 833: There seems no 
use case for attribute extensibility in the ValidValue, ValidValueRange 
and StaticValue element definitions, as attribute values of the 
resource properties will appear on the child elements.
Recommendation: Remove attribute extensibility from ValidValue, 
ValidValueRange and StaticValue element definitions.

Lines 904 - 906: With two mechanisms for publishing the RMD, we need to 
specify a precedence order.
Recommendation: Both the portType and Resource Property methods are 
permitted. When both are present, the resource property instance takes 
precedence. This supports dynamic addition of metadata in 
implementations of a fixed porttype, at the cost of a possibly 
verification that assumptions made based on the potyType reference (if 
present) are still correct.

-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE

     +44-208-606-4649 (Office)
     +44-208-606-4539 (Fax)
     +44-7768-807526  (Mobile)



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