- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Thu, 10 Mar 2005 12:35:56 +0900
- To: Jonathan Marsh <jmarsh@microsoft.com>
- Cc: public-ws-addressing@w3.org
On Mar 8, 2005, at 11:51 AM, Jonathan Marsh wrote:
>
> A straight through read of the Core draft brought a few editorial items
> to my attention.
>
> 1) The Short Table of Contents does not provide significant value over
> the complete version since the complete version fits easily on a single
> screen with room to spare. I assume this is automatically generated by
> the build process. Can we drop the Short Version?
>
Done.
> 2) Section 2.2 has this line:
> /wsa:EndpointReference/wsa:ReferenceParameters/[reference parameters]
> which departs from the standard notation. I think it should be:
> /wsa:EndpointReference/wsa:ReferenceParameters/{any}
>
Done, this was a result of my mixing up the resolution to issues 7 and
44.
> 3) The following extensibility points for attributes are not documented
> in the spec:
> /wsa:EndpointReference/wsa:Address/@{any}
> /wsa:EndpointReference/wsa:ReferenceParameters/@{any}
>
> I assume the standard boilerplate would describe these: "This is an
> extensibility mechanism to allow additional attributes to be
> specified."
>
Done.
> 4) Section 3 states (awkwardly):
> "[source endpoint] : endpoint reference (0..1)
> Reference of the endpoint where the message originated from."
>
> Suggest rewording to "Reference to the endpoint at which the message
> originated."
>
Done
> 5) Section 3.1 doesn't discuss whether attribute extensions are
> allowed.
> Rather than introducing lots of /@{any} notation, perhaps we could
> state
> generally that extension attributes are allowed.
>
Done.
> 6) Many sections and subsections don't have explicit ids (e.g. Security
> Considerations). It's nice to have readable IDs for linking to the
> spec
> with fragments.
>
Done.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.
Received on Thursday, 10 March 2005 03:36:00 UTC