"Arthur Ryman added a comment - 07/May/10 03:30 PM
Dilshan, If programmers need to use both the read-only and the read-write interfaces together, then it would be awkward. I assume programmers will only use one or the other. Leaving "Editable" in the names is OK. "
Above suggestion is much more clear with your assumption ,but practically this is not always possible. As an example if I take the use case mentioned in your 2nd point modifying existing WSDL file ; first WSDLReader returns object of Description type and then in order to modify the content user should cast into editable.Description, here we can see both read-only and read-write APIs together. In such scenarios user needs to use both APIs together.
Also it is not possible to pre-determine the exact place where the user move in to one API to a another , as an example to add new child component to a Binding component of a existing WSDL file user has following two ( or more) options.
1.) First read the file, cast Description into editable.Description and retrieve child components to reach to the particular editable.Binding component and add new child component.
2.)First read the file and use Description component to reach to the particular Binding and once he want to add new child component cast Binding into edtable.Binding.
I have two suggestion for this
1.) Simply use "Ed" or "E" like prefix instead "Editable" to short the new interface names.
2.) Use Arthur's suggestion with a convention /policy.
We can introduce a policy something like if a user plan for a modification in future he should move into the read-write API at the top level by casting Description into editable.Description this will reduce mixing components from both APIs together. Also it is possible to encourage user to follow this policy by introducing a method like makeEditable() on Description interface ( public editable.Description makeEditable()
). WDYT ?
" Arthur Ryman added a comment - 07/May/10 03:30 PM
2. The file serialization strategy relies and naming conventions to generate the file names. This means you can't handle the important use case of editing an existing set of WSDL 2.0 files. Suppose you start with a set of WSDL 2.0 files and want to modify them. You should serialize them back into the same files. This works unless the user creates new top-level components. In this case the user should be able to specify the name of the file. So I think the interface for creating a new top-level component should let to specify the name the file, or maybe an output stream. "
I'm little confusing with this , Component level API does not contains any knowledge about physical constructs of a WSDL doc , there is no Imports or Includes. Once the user read a WSDL file and serialize back to the file using WSDLWriter it is necessary to preserve the physical constructs but when he serialize using Component level API is it necessary to preserve same physical structure ?
IMO when he serialize using Component level API he can select one of the defined strategy and this behavior is same for both newly created docs and existing docs .