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: RE: [wsrf] Action item to review updates to RMD

I also had this same AI. I have marked up Tim's mark-ups with additional
comments. The highlights are:

1) There is some old text that implies that the specializes attribute
still exists that should be cleaned up.

2) We will want to create a short form namespace as we did nor the other

3) There is a reference to an AppNotes topic that does not seem to
exist. It is probably because WSRF118 has not been completed. However,
with the removal of specializes, I suspect we do not want this topic at
all and the reference should be removed.

4) TC membership is missing from acknowledgements

5) Re WSRF119: This decision was made before we added the xs:any back. I
think we should revisit the renaming of the MetadataDescriptor element.
The spec did not rename it and I think we should leave it that way.

6) Re WSRF120: Done, except for pseudo-schema as noted by Tim.

7) Re WSRF155: Done. I recommend that the order of text be the same as
the order of the pseudo-schema.

8) Re WSRF163: Done.

The marked up document can be found at:


-----Original Message-----
From: Tim Banks [mailto:tim_banks@uk.ibm.com] 
Sent: Wednesday, January 25, 2006 4:23 AM
To: danjemiolo@us.ibm.com
Cc: wsrf@lists.oasis-open.org
Subject: [wsrf] Action item to review updates to RMD

Hi Dan,

I had an action item to review some specific updates as a result of
issue resolution (see below), but I took a look at the whole spec
anyway.  The marked-up version is here:


Re issue 118: The text at lines 646-658 in [1] doesn't explain how to do
the copy/paste in the context of the Identification and Operatign
Systems portTypes illustrated in theRMD spec.  Specifically, two things:
First,  how does one merge the elements:
(from http://example.com/ns/OperatingSystem)
                        <Property path="id:ResourceType">

and (from http://example.com/ns/Identification)
       <Property path="id:ResourceID"
               modifiability="read-only" />

to  achieve the augmentation described in line 368 of [2] What happens
in the general case & would happen if the merge entailed conflicting

In any, case, I think the example of OperatingSystem (line 331 of the
spec) should show the merged version.  There was a discussion of similar
concerns in issue 120, but this effect seems to have been overlooked.

Second, we should say what happens to the interface attribute of the
merged MetadataDescriptors.

Also, the UML in figure 2 needs to be corrected in respect of the
cardinality of the constrains/describes  relationship.  It differes from
figure 1, which seems to me to be correct in that only one <Property>
describe each ResourceProperty.   Should this rule be enforced in the

119: This seems to me not to have been implemented.   The minutes from
27th say "rename metadataDescriptor to
but section 7 retains the old name.
155: Ok.
163:  The schema in the appendix is Ok, but the separate file at [3]
seems not to contain any schema...


Regards, Tim Banks.
ESB Architecture, Hursley, UK.
Phone:   Int: 245639 ,   Ext: +44 (0) 1962 815639

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