Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.w3.org/2001/tag/doc/abstractComponentRefs below:

Abstract Component References

This document has been developed for discussion by the W3C Technical Architecture Group. This finding addresses issue abstractComponentRefs-37. It does represent a draft of the consensus opinion of the TAG.

Publication of this finding does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time.

Additional TAG findings, both approved and in draft state, may also be available. The TAG expects to incorporate this and other findings into a Web Architecture Document that will be published according to the process of the W3C Recommendation Track.

Please send comments on this finding to the publicly archived TAG mailing list www-tag@w3.org ( archive).

The TAG consensus is that description languages - such as WSDL, XML Schema, OWL - may use URIs that include fragment identifiers to identify abstract components described by that language. The TAG supports the use of fragment identifiers in the abstract component identifiers defined by the WSD working group. [Definition: An abstract component is a descriptive link to a resource]. In the WSDL language, the descriptive links are the constructs the WSDL language that describe Web services.

Description languages, such as WSDL and RDF, provide a language for describing things, known in the web context as resources. In the WSDL case, the resources are Web services. The name "Web service description language" is appropriately chosen for a language to describe resources that are web services. The description language defines the constraints on how to represent the description information. As defined in the web architecture, instances of a language are called components. Given that these components are information about a different resource, the different resources are called abstract components. A description of a resource must necessarily always refer to the resource being described and so the description component is always a link. Description languages typically provide mechanisms for identifying the abstract components, and these are called abstract component identifiers.

The identifier used to identify an abstract component should be useable to retrieve a representation of the corresponding abstract component description.

This implies descriptions should be deployed to be retrievable by simple dereference of the relevant identifier.

The TAG does believe that the issue of identifying abstract components and the use of namespace names has architectural implications for the Web. The TAG has consensus that a vocabulary can recommend that an instance of the vocabulary is available upon de-referencing the namespace name.

Description languages that identify abstract components should make available an instance of the language at the URI used for identifying the abstract component.

A typical base URI is the namespace name for the instance of the language.

The TAG is working on a namespace name format [issue8] . This format and the related fragment identifier syntax are not sufficiently advanced in the W3C process for the TAG to recommend that a working group use them. The abstract component identifiers as defined in a particular language, and the relationship to the description language syntax, the fragment identifier syntax, the use of a namespace name document, and the namespace name document fragment identifier syntax is not clear at this time. The TAG expects to continue work on this area.

As for the particulars of the syntax, the TAG does not wish to delve into syntax design of the WSD fragment identifier syntax, believing that the WSD WG is better qualified for such activities. Members of the TAG did express support for Option 1 in the Namespace name and fragment identifier syntax section, but this is not a consensus opinion and the TAG plans no further elaboration on the WSD specific syntax. The TAG has taken up the issue of documenting URI construction best practices [issue40] which may prove useful to the WSD and other Working Groups.

The WSDL problem is how to refer to the abstract component specified in the WSDL language. Thus the WSDL problem is described as abstract component references. The WSD Working Group performed an analysis of requirements, possible solutions and proposed a solution, explained at [RymanExplanation].

This requirements section elaborates on the WSD WOrking Group's analysis of requirements. The elaboration is based upon further analysis of the solutions and numerous discussions.

• It must be possible to identify each abstract component in a WSDL vocabulary with a URI.

• It should be simple to create the WSDL abstract component constructs that are used for the URI.

• It should be simple to create the URI

• It should be possible to retrieve a namespace name document given an abstract component reference if the namespace name is used as part of the URI.

• It should be possible to extract the symbol space information from the URI. The WSDL specification uses the symbol space name as the top-level specifier of the symbol space for the names defined by WSDL. There is an open TAG issue on the use of metadata in URI [Issuemetadatainuri-31] . The TAG does not offer an opinion on the relationship between symbol space names and metadata nor the suitability of this within URIs.

• It should be extensible in order to identify components described by WSDL extensions, ala soap:binding, soap:operation, soap:address, soap:body, soap:action, soap:fault, soap:header, soap:headerfault, http:address, http:binding, http:urlEncoded, http:urlReplacement, mime:content, etc.

• It should re-use existing naming or identifying constructs and fragment identifier syntax

The requirement for using relative URIs is not listed as a criteria here. It appears it is a "nice-to-have" but not a significant factor in any recommendation or decision.

A WSDL fragment of the form:

Example: Sample WSDL Fragment

<definitions name="TicketAgent"
          targetNamespace="http://airline.wsdl/ticketagent/">
          <portType name="TicketAgent"> <operation
          name="listFlights" parameterOrder="depart origin
          destination"> <input name="listFlightsRequest"
          message="tns:listFlightsRequest" /> ......
          </definitions>

This section describes the various abstract component identifier syntax solutions and fragment syntax changes for WSDL abstract component references that have been collected during the course of this finding.

Each solution met a varying amount of the requirements. No one solution met all requirements.

Option #1: query-string like format

Suggested at TAG Oct 2003 F2F [2003110tagf2f] . Query string format based upon query string with single argument proposal, listed later in this document.

Sample URI is

http://airline.wsdl/ticketagent/#input=TicketAgent.reserveFlight.reserveFlightRequest

Option #2: symbol space name followed by parenthesis containing component identifier within symbol space.

Original WSDL Proposal.

The sample URI is

"http://airline.wsdl/ticketagent/#input(TicketAgent/listFlights/listFlightsRequest)".

Pros:

• simple to author WSD constructs.

• simple to author URIs

• symbol space is apparent

• Option #1 does not use parenthesis.

Cons:

• Unsure how extensions are identified.

• Requires inventing WSDL specific fragment identifier syntax

Add an ID attribute and retain the name attribute

The WSD sample becomes:

<definitions id="TA" name="TicketAgent"
          targetNamespace="http://airline.wsdl/ticketagent/">
          <portType id="TAPType"name="TicketAgent">
          <operation id="TAPTypeLOF" name="listFlights"
          parameterOrder="depart origin destination"> <input
          id="TAPTypeLOFReq" message="tns:listFlightsRequest"
          name="listFlightsRequest"/> ......
          </definitions>

The URI sample is "http://airline.wsdl/ticketagent/#TAPTyleLOFReq"

Pros:

• re-use at least the ID portion of XML fragment identifier syntax

• extensions are identifiable

Cons:

• hard for authors of WSD documents.

• hard to manage the space of Ids to guarantee URI identifies single component across compound WSDL documents

• Overlap between names and ids.

• Symbol space is not apparent.

Require that name attributes be unique.

The WSDL fragment becomes

<definitions name="TicketAgent"
          targetNamespace="http://airline.wsdl/ticketagent/">
          <portType name="TicketAgentPortType" >
          <operation
          name="TicketAgentPortTypelistFlightsOperation"
          parameterOrder="depart origin destination"> <input
          name="TicketAgentPortTypelistFlightsOperationlistFlightsRequestInput"
          message="tns:listFlightsRequest" /> ......
          </definitions>

The URI sample is

"http://airline.wsdl/ticketagent/#TicketAgentPortTypelistFlightsOperationlistFlightsRequestInput"

Pros:

• extensions are identifiable

Cons:

• Reinvents some of ID constraints.

• hard for authors of WSDL documents.

• Symbol space is not apparent

The sample URI is

http://airline.wsdl/ticketagent/#xmlns((w=http://schemas.xmlsoap.org/wsdl/)xpointer(//w:portType[@name="TicketAgent"]/w:operation[@name="listFlights"]/w:input[@name="listFlightsRequest"])

Pros:

• re-use XPointer syntax

• Symbol space is apparent

• extensions are identifiable

• easy to author WSDL documents

Cons:

• complex syntax

• requires XPointer processor

• URI may identify multiple components.

• XPointer is not a recommendation.

Note:

XPointer element() Scheme [xptr-element] , XPointer Framework [xptr-framework] , and xmlns() Schema [xptr-ns] are Recommendations.

Full Xpointer [xpointer-full] is a WD that has no active work on it.

Sample URI #1 is:

"http://airline.wsdl/ticketagent/#element(ticketagent/listFlights/listFlightsRequest)"

Sample URI #2 is:

"http://airline.wsdl/ticketagent/#element(ticketagent.listFlights.listFlightsRequest)"

The "." separator may be better suited than / within parens, due to parser implementation issues.

Pros

• re-use element() syntax

Cons

• Type is not apparent

• URI may identify multiple components.

• doesn't handle extensions

• roy:use of parens is goofy

Sample URI is

"http://airline.wsdl/ticketagent/#xmlns(w=http://schemas.xmlsoap.org/wsdl)w:input(ticketagent/listFlights/listFlightsRequest)"

Pros:

• Symbol space is apparent

• handles extensions

Cons:

• URI may identify multiple components.

• URIs are complex to create

• need to develop WSD specific fragment identifier syntax.

• Uses balanced parens

XML Schema component designators description at [scuds] . Some rationale for Schema's decisions on Component Designators at [noahonscuds] . The sample URI is

"http://airline.wsdl/ticketagent/#xmlns(ta=http://www.airline.wsdl/ticketagent/)wsdl(/portType(ta:TicketAgent)/operation(listFlights)/input(listFlightsRequest))"

Pros:

• Symbol space is apparent

• extensions are identifiable

Cons:

• complex syntax

• Schema component designators still under development

• Uses balanced parens

Proposed and described in [useURN] .

The URI sample would be

"urn:wsdl:airline.wsdl:ticketagent:listFlights:listFlightsRequest"

Pros:

Cons:

• embeds URIs into URNs

• URI not dereferenceable

• Unsure how extensions are identified

• No advantage over http: URIs with respect to longevity as a new URN needs to be minted any time the interface changes.

First proposed in in [rddl-fragid] . First raised in [200111tagf2f]

Sample URI is

"http://airline.wsdl/ticketagent/#wsdl/input.TicketAgent.listFlights.listFlightsRequest"

Pros:

• Symbol space is apparent

• incorporates RDDL into Web services

• Could unify schema, wsdl, other description languages with namespaces.

Cons:

• Idea is a barely beyond a twinkle in our eyes. It requires specification of RDDL fragment identifier syntax, and typical time to develop issues.

• Unknown whether it will actually solve the problem.

• Unsure how extensions are identified.

• roy:we don't need another universal media type.

Suggested in Mar 24th telcon [mar24telcon]

Quoting the suggestion: "In the CMS world, a compound hierarchical document is no different from a hierarchical directory system -- all names are hierarchies and the names are separated by "/" all the way down to the smallest atom of content. WSDL defines a compound document namespace rooted at its namespace URI. So, add a slash and define the hierarchy below the namespace URI according to WSDL.". A disagreement with using frag-ids in names in [royonfragsasnames]

Sample URI is

"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest"

roy:preferred approach

Option #2 URI is

"http://airline.wsdl/ticketagent/input/TicketAgent/listFlights/listFlightsRequest"

Option #3 URI is

"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest/input"

Option #4 URI is

"http://airline.wsdl/ticketagent/TicketAgent/listFlights/listFlightsRequest;input"

Roy:preferred approach if input is required

Option #5 URI is

"http://airline.wsdl/ticketagent/input(TicketAgent/listFlights/listFlightsRequest)"

Pros:

• Option #2,3,4,5 has symbol space apparent

• Does not require a WSD syntax

Cons:

• Can't tell where the namespace name ends and the name begins Roy:So?

• Symbol space is not apparent in option #1.

• #5 has balanced parens.

Option #1

Proposed in [usequery]

Sample URI is

"http://airline.wsdl/ticketagent?portType=TicketAgent&operation=listFlights&input=listFlightsRequest"

Option #2

Proposed in [jonathanonusingquery] . This suggests a single name with a value that uses periods as separators.

http://airline.wsdl/ticketagent/?wsdl-input=TicketAgent.reserveFlight.reserveFlightRequest

Pros:

• Symbol space is apparent

Cons:

• Overrides a portion of the URI space

• Option #1: No hierarchy of names

• No prevention of namespace conflicts. Not sure how much of this is a problem for referring to WSD documents.

• Extensions not supported.

• need to develop WSD specific query parameters.

• A dereference operation will require that a WSDL document not be returned, rather the abstract component. Otherwise the client cannot interpret the document properly.

Notes:

I wonder if there would be a way of getting QNames into this for extensions.

Roy: this solution defeats the purpose of assigning names

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4