[email]

At the F2F today, Jack said that the Description component was not important for the RDF mapping.

I think the Description component is important because it acts as a container for top level components. It provides a context. A top level component might be a member of many Description components, e.g. if it gets imported in many contexts. The Description component itself models a component model instance in that it represents a set of related components.

[email]

This WSDL test case has element references that are prefixed with a namespace that is schema imported within <types>, however the schemaLocation URL cannot be resolved (java.net.UnknownHostException: greath.example.com). A wsdl processor might use a catalog to resolve such a host name, but I guess that's not the objective of this test case.

See: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/documents/good/CreditCardFaults-1G/use-credit-card-faults.wsdl

  
]]>

I think there is another problem too. This wsdl imports another wsdl document containing a schema import of "credit-card-faults.xsd". That schema should not be visible to the top level wsdl, unless it imports the schema directly in its <types> element (i.e. if WSDL B xs:imports Schema X and WSDL A wsdl:imports WSDL B, Schema X is not visible to WSDL A. WSDL A must xs:import Schema X directly). However in this test case, the top level wsdl does have element references to that schema's namespace. For this test case to work, I think the top level schema needs to xs:import "credit-card-faults.xsd" in its <types> element.

See [email] 1. section 2.2, "expectedMediaType attribute": is set up much as if it were an "Accept" header, complete with q (quality) values. Accept-extensions are explicitly not permitted, nor are additional content selection attributes provided. We think that it might be important that the remainder of the Accept-* set of content negotiation headers be provided for here. Of particular interest to I18N are the equivalents to HTTP's Accept-Language and Accept-Charset headers. These values may be important in describing in a Web service the preferences or capabilities of the service provisioned at the end point. For example: a Web service that performs spell checks might only support content in a specific language. Or a particular device (such as a mobile phone) might support only a limited range of encodings. The ability to provide meta data about the character of the content that can be sent (either informatively to the end user or because content not matching the value will be rejected) seems like an important capability to consider. Also it is possible to imagine services that will use this information to perform HTTP requests on behalf of the service provider. That is, consider the difference between: <xs:complexType name="PurchaseOrderType" type="xs:base64Binary" xmime:expectedMediaType="application/xml"/> And: <xs:complexType name="PurchaseOrderType" type="xs:base64Binary" xmime:expectedMediaType="application/xml" xmime:acceptLang="ja" xmime:acceptCharset="utf-8, *"/>

See [email] 2. section 3. "Declaring media type for binary data": there are two examples in-line in the text (one is image/png and the other is text/xml;charset=utf-16). The XML example is good, in that it uses a charset parameter. However, we note: a. There should be mention that the charset parameter for textual types is STRONGLY RECOMMENDED similar to that in the other binary XML documents. Cf. [1], which says: If the media type identified by the value of an xmime:contentType attribute information item is a text based media type then the value of the xmime:contentType attribute information item SHOULD include a charset parameter. b. There should probably be an example of the charset parameter in use. The examples (quite properly) use a binary image as an example, but it is entirely probable that this mechanism will be used to send content such as HTML or XML documents too.

See [email] 3. We note that the document uses the namespace prefix 'xmlmime'. Isn't this prefix illegal per XML Namespaces (http://www.w3.org/TR/REC-xml-names/#xmlReserved)? Perhaps another prefix should be used, such as 'xmime' as in the quote from [1] above.

[email] Please change the document so that it is clear which sections and which references are normative and which are informative.

[email] The document has several sections labeled "Editorial note", these use table markup but do not really contain tabular data, please change the markup to something else, e.g. <dl> or just a <p> with a <strong> leading "Editorial note:". Also note that "Editorial note:" is not a proper table summary (as specified in the summary attribute).

[email] The xml-infoset reference refers to the first edition of the document, please change it to refer to the second edition.

[email] Section 1 has an example "text/xml; charset=utf-16", please change this example to something else, use of text/xml is discouraged and for XML documents using a charset parameter is claimed to be unnecessary and harmful.

[email] Section 1.1 states:

   Namespace names of the general form "http://example.org/..." and
   "http://example.com/..." represent application or context-dependent
   URIs [IETF RFC 2396].

Please clarify in the document what you mean here, the statement does not really make sense to me.

[email] Section 1.1 notes "http://www.w3.org/2004/11/xmlmime" is defined by the document, the namespace URI is too long and it generally makes little sense to put dates into namespaces URIs, please change this at least to e.g. "http://www.w3.org/2004/xmlmime" to be consistent with a wide range of W3C namespaces URIs.

[email] Section 2.2 states

   The value and the meaning of the expectedMediaType attribute is
   similar to the value allowed for the 'Accept' header defined by HTTP
   1.1 specification, Section 14.1 [IETF RFC 2616] and MUST follow the
   production rules defined in that section. The 'q' parameter defined by
   HTTP 1.1 specification, Section 3.9 [IETF RFC 2616] is allowed, but
   other accept-extensions are not allowed.

The production rule in RFC 2616 cannot be used here, it is defined in terms of octets while the information item is a sequence of characters.

In order to re-use the production rule you would need to define how to map the characters to octets before attempting to match; the alternate solution would be to create a new production rule that is defined in terms of characters.

Please change the section so that it is clear what the differences are, you note these are "similar" and cite one difference, but it is not clear to me whether this is the only difference.

Please change the section so that it is clear which production rule you actually mean, section 14.1 of RFC 2616 has several. It would seem that you mean the production rule for "Accept", but as that contains "Accept:" you probably don't, so you might mean the Accept production rule without the leading "Accept:" or media-range.

Whatever you do, please ensure that parameters can be used, e.g.

   x:expectedMediaType = 'application/xhtml+xml;profile=http://...'

[email] It seems that re-using the Accept header syntax here makes it impossible to state that any kind of "XML" is accepted, I however think that this is an important use case for such an attribute. It is often not possible to include XML documents in other XML documents (e.g. if the document has a document type declaration). Using e.g.

   x:expectedMediaType = 'application/xml'

would likely not work as e.g. image/svg+xml does not match. I think the syntax should be extended so that it is possible to express that XML is expected whatever type might be used. This would be useful e.g. for a web service interface to the W3C Markup Validator.

The attribute could allow a special string like

   x:expectedMediaType = 'xml'

in place of a media-range, this would allow the W3C Markup Validator to use it like

   x:expectedMediaType = 'xml, text/html, text/sgml'

If accept-extensions continues to be disallowed, please include a rationale for the exclusion in the document.

[email] Section 3.1 states

   When the expectedMediaType annotation attribute has a wildcard ("*")
   or a list of acceptable media types, the schema SHOULD require the
   contentType attribute to be present.

This seems to imply that

   x:expectedMediaType = '*'

would be allowed which does not seem to be the case. If the intention is to allow this syntax, please change the definition accordingly, if it is not allowed, please re-word the paragraph to make it clear what you mean."

[email] Section 3.1 states

   The value of the contentType attribute, if present, SHOULD be within
   the range specified by the expectedMediaType annotation attribute, if
   specified in the schema.

It is not clear to me how it is determined whether this requirement has been met. If there is an algorithm, please reference it normatively, or provide your own.

[email] Section 2.1 does not define the lexical or value space of the attribute, it states it is xs:string but it would seem you would rather want to say that this relates to RFC 2616 Content-Type in some way. When fixing this please consider my remarks about the "Accept:" header reference here, too.

The XML Schema for the attributes seems overly lax, for example, as currently defined, x:expectedMediaType requires that the string has at least three characters, please change the definition so that a XML Schema Validator can determine conformance of the attribute value as much as possible.

[email] Please add a namespace prefix to all occurences of "expectedMediaType" and "contentType" in the document where you do not specifically refer to the local name of the attribute, this helps to avoid misunderstandings by people not totally namespace-aware and make the document more readable.

[email] The reference to XOP in this Working Draft http://www.w3.org/TR/2004/WD-xml-media-types-20041102/ is to the Working Draft revision of XOP at http://www.w3.org/TR/2004/WD-xop10-20040209/ and should be to the CR version http://www.w3.org/TR/2004/CR-xop10-20040826/ as it incorporates the xmlmime:contentType attribute defined in this Working Draft.

[email] The introduction to the 2 November 2004 Last Call WD of "Assigning Media Types to Binary XML" states that XML Schema is not required in order to make use of the xmlmime:contentType attribute.

Unfortunately, without type information it is not possible to reliably distinguish between elements with base64 binary and hex binary content: for example, the content "0000" decodes to the octets "0x00 0x00" in hex binary, but "0xD3 0x4D 0x34" in base64 binary.

Therefore, either an xmlmime:contentTransferEncoding is required for schema-free operations, or the recommendation should specify the use of xsi:type with the values "xs:base64Binary" and "xs:hexBinary" for use in schema-free operations.

I would prefer the latter alternative."

[email] Table 1. "Prefixes and Namespaces used in this specification" defines the prefix "xmlmime" for the namespace URI "http://www.w3.org/2004/11/xmlmime". This is an invalid namespace prefix since a namespace prefix is not allowed to start with the reserved string "xml". The XML spec says:

===
Namespace Constraint: Leading "XML"
Prefixes beginning with the three-letter sequence x, m, l, in any case 
combination, are reserved for use by XML and XML-related specifications.
===

[email] I'm suspicious of the attempt to use HTTP "accept" headers to "indicate in XML Schema what media type the character content of an element will have."

In practice, HTTP Accept headers have turned out to have severe interoperability problems, and have not been useful for content negotiation. It's a bad practice to try to follow something that hasn't worked for the stated purpose.

For example, a description of "image/*" is, in practice, not useful because of the wide variety of image types that are likely *not* implemented.

In general, indicating ranges of acceptable media type is quite difficult; the best practice in this area is likely to be either CCPP (www.w3.org/Mobile/CCPP/) or media feature expressions (RFC 2533 plus RFC 2913). However, neither have widespread deployment and interoperability experience.

[email] I think the document suffers from an editorial problem which starts with the title. "text/xml;charset=utf-8" is not a "IANA media type" or a "media type token", it is a "content-type string", the difference being that a content-type string starts with a media type followed by parameters for that type.

I think it's important to avoid confusion by careful editing:

• The title: "Assigning Media Types to Binary" probably should be "Describing Media Content of Binary"
• The schema definition could be 'expectedContentType' instead of 'expectedContentType' (if a single value; if a more complex type expression language is allowed, then rename accordingly).
• "Declaring media types for binary data" => "Declaring Content-Type for binary data".
• the name of an IANA media type token" => "a valid content-type string"

[email] [normalized value]: I think defining a normalization for content-type strings is difficult, and you should avoid it.

[email] I am confused as to why the mime:contentType attribute is required.

It would seem that applications that expect binary content will have to be hardcoded to support the elements in which that content appears anyway, so supporting an attribute on those elements as well seems like it wouldn't require the use of namespaces.

As a data point: XLink is used in SVG on elements that refer to external resources, as in <style xlink:href="">. The theory is that by reusing the same attribute for all links, the implementation is somehow able to reuse code. However, in practice, the UAs have to have code for each embedding mechanism, and the attribute doesn't help at all by being in the XLink namespace.

So while I can understand that XML Schema may need to be extended to support MIME types as a first-class data type, it would seem that the actual mime:contentType attribute is superfluous.

See [email]

[email] 2a) Using xs:string is almost certainly not what you want -- that makes whitespace variation significant, so that e.g.

  xmlmime:contentType="image/png "

is not the same as

  xmlmime:contentType="image/png".

I would recommend xs:token instead.

[email] 2b) Please provide a concrete reference for "IANA media type token".

[email] 2c) In example 1, you probably mean

  <xs:restriction base="xmlmime:base64Binary">

[email] In example 4, you probably mean

  <xs:complexType name="JPEGPictureType>
   <xs:complexContent>
    <xs:restriction base="xmlmime:base64Binary"
                    xmlmime:expectedMediaType="image/jpeg"/>
   </xs:complexContent>
 </xs:complexType>

See [email]

Should the expected media type be an attribute instead of an appinfo annotation? WG substantially in favor of this if tooling doesn't prevent it.

[email] The schema for SOAP Binding [1] is old and out of sync with Part 3. What is the schemaLocation for the schema for HTTP Binding?

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email]

[email] * A short, formal definition of what a Fault is, in WSDL terms, may be useful (not necessarily in this document, but somewhere).

[email] * Section 2 uses "generation" in reference to Faults, which seems to have a different meaning than in SOAP. When A SOAP Fault is generated, it is not necessarily transmitted on the wire; here, the implication seems to be that it is. Suggest using "Fault transmission," "Fault delivery," or "Fault destination" throughout instead. This would make the first sentences in the section something like: "WSDL patterns specify the destination and transmission of any Faults generated in a message exchange using standard rules. The most common such rules are defined here and referenced by patterns later in this document. A Fault, regardless of the rule in effect, terminates the message exchange it occurs in."

[email] * Can the destination or occurrence of a Fault be overridden dynamically? E.g., can I specify a SOAP header that says "send any faults over there" or "keep that fault to yourself"?) If so, the mechanisms in section 2 should be couched as "Default Fault Generation Rules," or "Default Fault Transmission Rules", with appropriate explanatory text, if the previous suggestion is accepted.

[email] * It might be advisable to differentiate the MEPs described here from the messages in underlying protocols (to use SOAP terminology); perhaps "Interface Message Exchange Patterns"? (I don't feel strongly about this, just a suggestion

[email] * The draft uses "patterns" and "WSDL patterns" often; suggest either normalising to "WSDL Message Exchange Patterns" or beginning the introduction with "Web Services Description Language (WSDL) message exchange patterns (hereafter, 'patterns')..."

[email] Part 2 refers to {label} properties, whereas part one uses {message label}; should these be the same?

[wg discussion relative to issue 169.]

[wg discussion relative to issues 157, 167.]

[email] Part 1, 2.11: "A Binding Operation component describes a concrete binding of a particular operation of an interface to a particular concrete message format."

This doesn't hold; the binding operation isn't constrained to a single concrete message format, and also describes protocol details.

[email] - 2.1.1: "Type system components are element declarations drawn from some type system. They define the [local name], [namespace name], [children] and [attributes] properties of an element information item."

This effectively limits web services to an Infoset data model. However, in other places it the document indicated that other data models are allowed by WSDL; which is it? E.g., in 2.5.1: "If a non-XML type system is in use (as considered in 3.2 Using Other Schema Languages) then additional properties would need to be added to the Message Reference Component (along with extensibility attributes to its XML representation) to allow associating such message types with the message reference." What is the benefit of this approach, instead of just using a more neutral reference mechanism (i.e., "content" or "ref" instead of "element") to determine the type of a message?

To me, this is a base requirement for WSDL; a good proportion of the content on the Web is NOT most naturally expressed or modeled as an XML Infoset, and even WSDL itself has chosen to specify its data model in a layer above the Infoset (the "Component Model"). Why should the messages WSDL describes be confined to the Infoset, or prejudiced by XMLisms like "element"?

I suggest removing any language (such as that above) that requires messages to be modelled as Infosets, and changing attributes named "element" (and similar) to "content" or another, more neutral term. I do not believe that this is a large change, nor is it one that will impact existing implementations greatly, but it will provide great benefit to the Web.

[email] - 2.1.1: The component model is not well-defined; no where is it said that components have properties, nor is are their aspects explained, and the {} notation's significance is not documented.

[email] - 2.1.1: "imported/included" - There needs to be a reference to these processes. Also, the definition of how to arrive at a component model and how to interpret it are intertwined; while it makes sense to specify the semantics and mapping of individual components together, the separation of the import and exclude functionalities is awkward.

[email] - 2.1.1: "an unambiguous name for the intended semantics of the components." -> "an unambiguous name *space* for the intended semantics of the components." (the namespace isn't used as a name on its own, is it?)

[email] - 2.1.1: Why are QNames, rather than URIs, used to identify components? If there are good reasons for not using the primary identification mechanism in the Web, they should be documented here, along with caveats as to their use (e.g., if signing content, etc). If not, URIs should be used.

[email] - 2.2.1: What are the semantics of interface extension? E.g., how are duplicate operations in the set handled? This is mentioned in a few places, but not comprehensively documented.

[email] - Table 2-2 (and elsewhere): What is an "actual value"? Does this imply that it is not the [normalized value]?

[email] - 2.3.1: Why is it advantageous to define a fault at the Interface level, if it's just repeating information in the operations?

[email] - 2.4.2.3: The style attribute has a very loose semantic; it seems purpose-built for RPC, and therefore is effectively yet another extensibility mechanism. Also, it is readily imaginable for an operation to have more than one style; e.g., RPC as well as web:method="POST" semantics. Therefore, it needs to be able to carry multiple values; while this could be accommodated by making the value a list of URIs, I suggest it would be better to define this as an rpc-specific attribute with a boolean value (e.g., ext:rpc="1").

[email] - 2.4.4: This section implies that you MUST define your messages in XML Schema to use RPC style; such a restriction is not necessary, as long as it is functionally equivalent.

[email] - 2.4.4: "hence the rules which refer to the output element do not apply." Read literally, this has the (unintended?) effect of obviating the first rule.

[email] - 2.8: The term "properties" is used throughout to denote a part of the component model; this section redefines it as something similar but different.

[email] - 2.9.1: In many places in the spec, the semantics and constraints on component properties (e.g., optionality) are described in the Infoset mappings, rather than in the properties themselves. For clarity and applicability to other mappings, it would be better to place them at the component model level.

[email] - 2.11.2: "A REQUIRED ref attribute information item" - this requires all binding operations to refer to corresponding interface operations, despite earlier indications in 2.9.1 that bindings could be specified generically "across all operations of an interface." If that is true, how should one do so?

[email] - 2.12.1: It seems wasteful to duplicate the interface message into the binding if there is no additional information therein. Can it be omitted with no effect in this case? I.e., the specified properties only serve to identify the message, not to affect the concrete representation of it; it should be explicitly stated that the absence of those properties has no effect on the interpretation of the description.

[email] - 2.15: "Two components of the same type are considered equivalent if, for each property, the value in the first component is the same as the value in the second component." Are simple values compared character-by-character? Is any schema information (e.g., defaulting, for canonicalisation) necessary? How are sets compared? Will this work for Properties (which have an associated value)?

[email] - A.1: The "fragment identifiers" section of the media type registration needs to list the mechanism described in C.2.

[email]

- 2.1.2: Is the pseudo-schema normative? Where are its vocabulary and rules explained?

- 2.2.1: "The interfaces a given interface extends MUST NOT themselves extend that interface either directly or indirectly." What does "that" refer to? (would be good to mention recursion).

- 2.2.2.3: There needs to be a description of, or references to, the properties here (e.g., {message references})

- 2.3.1: "execution of an operation of the interface." -> "execution of *any* operation of the interface." ?

- 2.3.1: "The reason... is because that" Poor English.

- 2.3.1: "If a non-XML type system is in use... then additional properties would need to be added..." Poor English.

- 2.3.1: "...to allow associating such.." Poor English.

- 2.3.1: "to allow associating such message types with the message reference" Shouldn't that be *fault* reference?

- 2.5.1: "A Message Reference component associates to a message exchanged in an operation an XML element declaration that specifies its message content." Tortured English.

- 2.5.1: "Message Reference components are identified by the role the message plays in the {message exchange pattern} that the operation is using. That is, a message exchange pattern defines a set /meof placeholder messages that participate in the pattern and assigns them unique names within the pattern." What does this mean? This passage is *very* confusing.

- 2.5.1: "element" is used often, but not defined; is this Element Information Item?

- 2.6.1: "A Fault Reference component associates a Fault component that defines the fault message type for a fault that occurs related to a message participating in an operation. Fault Reference components are identified by the role the related message plays in the {message exchange pattern} that the operation is using." What? Please have pity on your readers.

- 2.6.1: "The purpose of a Fault Reference component is to associate..." Bad English. Try: "A Fault Reference component's purpose is the association of..."

- 2.6.2.1: "The ref attribute information item refers to a fault component." Shouldn't this be "*interface* fault component."?

- 2.11.1: "Interface Operation components are local to Interface components; they cannot be referred to by QName, despite having both {name} and {target namespace} properties. That is, two Interface components sharing the same {target namespace} property but with different {name} properties MAY contain Interface Operation components which share the same {name} property. Thus, the {name} and {target namespace} properties of the Interface Operation components are not sufficient to form the unique identity of an Interface Operation component. To uniquely identify an Interface Operation component one must first identify the Interface component (by QName) and then identify the Interface Operation within that Interface component (by a further QName)." What is the effect of this statement upon bindings? It doesn't place any direct requirements on them.

- 2.13: Shouldn't 2.14 Endpoints come before this section?

- 2.13.1: "A Service component describes a set of endpoints (see 2.14 Endpoint) at which the single interface of the service is provided." Circular definition; confusing.

[19 May FTF] How do annotations show up in component model? (currently limited to a "binary information element")

[19 May FTF] Pattern includes use of priority -- either explain relationship or get rid of it.

[19 May FTF] Explain why */* AND absence means this is opaque application data (i.e. application/octet-stream.

[19 May FTF] Explain why this proposal is limited to base64encoded?

[19 May FTF] Would like more examples: e.g using a static type -- i'm always going to use an image/jpeg. What would that look like?

[19 May FTF] Consider changing name from mediaType to contentType

[19 May FTF] Where should the annotation appear, on the type and/or the element?

[19 May FTF] Possible error conditions: mismatch between the media type attribute and the actual data.

[19 May FTF] Mismatch between value of media type attribute and pattern -- says nothing about the data.

May 2004 FTF: Don't like the ability to override a required feature in the interface with a non-required one in the binding.

[email]

[email]

[email]

[email]

[email]

[email]

[email] David Orchard proposed an attribute-based syntax for Web Method, rather than the generic property syntax proposed by Hugo.

[email] Is the Operation being invoked indicated by the name of the wsdl:operation, or by the operation of the binding? Spec is unclear.

[email] Pseudo-schema doesn't quite match the draft.

We need a WSDL 2.0 published schema to refer to to fix the table"

Should other choices be allowed to represent media-type values? Even if allowed, should this specification utilize them?

HTTP/MIME allow wildcards for declaring accepted media-types. Should this specification also allow wildcards for acceptedMediaTypes and/or mediaType attribute values, such as "image/*"?. There is already an issue recorded for this problem by XMLP as stated in XMLP Issue 443.

Should we describe reasonable paths through document for the purpose of concretely defining processor conformance? Alternatively should we just rely on document conformance?

@element="#any" means any single element, preventing the desctiption of messages with text, mixed content, or a sequence of elements. Are there compelling use cases for adding these capabilities? [email]

[email]

[email]

From 5 Mar 2004 FTF minutes: Are imports for the same namespace as the targetNamespace of the importing document allowed? If so, what does that mean?

From minutes of 5 Mar 2004 FTF, there may be inconsistencies between attributes refering to other components. We should use a single strategy, e.g. @ref, or @{componentType}Ref.

[email], factored at 26 Feb 2004 telcon. There doesn't appear to be an explicit way (post-message removal) to describe a message with an empty body.

[email]

[email]

[email]

[email]

[email]