PS> [PDF posted] Updated Documents

PS> [PDF posted] Updated Documents

McDonald, Ira imcdonald at sharplabs.com
Fri Nov 29 16:05:11 EST 2002


Hi Dave,

I distilled the MS Word source and just posted:

ftp://ftp.pwg.org/pub/pwg/ps/psi-spec94a.pdf

and (for the Web page link)

ftp://ftp.pwg.org/pub/pwg/ps/psi-spec-latest.pdf

Cheers,
- Ira McDonald
  High North Inc


-----Original Message-----
From: HALL,DAVID (HP-Vancouver,ex1) [mailto:dhall at hp.com]
Sent: Wednesday, November 27, 2002 8:35 AM
To: 'ps at pwg.org'
Subject: PS> Updated Documents


Hey All!  

We've updated the specification document to 94a:

ftp://ftp.pwg.org/pub/pwg/ps/psi-spec94a.doc

This version of the document has made a stab at getting the mandatory /
optional definitions into each of the methods comments section.

For the AddDocumentByReference, this was modified to return an array of
DocumentURI's, as a reference can refer to potentially more than one
document.  (For example, an email reference...)

Also, we have successfully updated the sample code to utilize the strongly
typed interfaces, and have made some soap calls with the new interfaces as
well!  The latest code can is linked from the web page.  We have a couple of
road blocks to overcome however - the current version of the Axis toolkit
has problems with the following constructs within the semantic model:

1)  Union - the way we are utilizing union to merge KWV and a pattern cause
Axis to generate no code for the element.
2)  NMTOKEN for enumerations.  Axis also doesn't appear to support this.

To address these two problems for the current sample code, I've taken a
snapshot of the PWG semantic model schemas, removed the Union declarations
(by simply defining the types directly as KWV), and changed the NMTOKEN
enumerations to string enumerations.

I don't believe that we should change NMTOKEN's to string in the semantic
model schemas, rather we should add support for NMTOKEN enumerations into
the Axis toolkit.

However, the union of KWV and string extension definition has me a bit
concerned that this is probably way beyond current toolkits capabilities.
Mainly because this would require that in the entity objects that the
toolkits generate, they would need to perform some sort of type checking
when a client tried to set the member variables to see if any restrictions
were violated.  Perhaps we could do the following:

Declare the elements that need to either be a keyword or a string extension
to have two sub elements - one defined by the KWV, and the other being a
string...

Any thoughts / suggestions?

Have a great Thanksgiving!

Dave Hall
HP




More information about the Ps mailing list