New TAG Issue: Sensitivity of URIs to AUCs

This message defines what is meant by the sensitivity of URIs to
Application and UI Contexts (AUCs), which is submitted as a new TAG
issue. A number of related sub-issues are also documented.

AUCs are sets of behaviours associated with a URI. Sometimes we want
to address these behaviours specifically, and this can lead to new
interface components or new identifier forms.

One example of an AUC is viewing an HTTP resource as plain text
regardless of its actual media type. This led to the "View Source"
interface component. But to enable this particular interface view to
be addressed and become part of the web, the "view-source:" URI scheme
was also invented.

Sometimes AUC identifiers (AUCIDs) can be provided by web services
through HTTP URIs. Identifiers for the "View Source" AUC could, for
example, have been provided through an HTTP URI service that proxies a
resource and modifies its media type.

When there are barriers to using HTTP URIs to identify AUCs,
alternatives must be found. In the case of View Source, it may have
been felt that a new URI scheme was a more vendor neutral approach.
But sometimes AUC URI schemes are vendor specific, such as with iTunes
URIs.

Those AUCs which are useful to identify may be described as open,
because they are open to reuse. Those which it is less desirable to
address may be considered closed or encapsulated.

View Source is chosen as a clear introductory example. Though it has
Provisional IANA registration status and inconsistent browser
implementation, there are many other examples of AUCs spanning the
whole range of standardisation:

* OS native application URI states, such as in email clients or music
players. These AUCs are especially pertinent with the proliferation of
mobile applications, but also include desktop apps.
* Web services that act upon other URIs, such as markup validators,
archive tools, and annotation services.
* Cache states, for example forcing the retrieval of the latest cached
version of a resource rather than fetching a new version from the
network.
* Separate identification spaces, such as XML namespaces, XML Schema
datatypes, XLink role, and RDDL natures (sometimes referred to as
"keys").
* Derived contexts such as the FOAF primary topic of a webpage, a
concept which is also referred to using the phrase "thing described
by".
* Undefined contexts, such as when a tag: URI is used in a browser,
and quasi-defined contexts, such as when duri: is used in a browser.

In some of these cases, AUCs may already have AUCIDs available for
them. Web service markup validators can have HTTP URIs; "thing
described by" has the tdb: URI scheme; and cache states have the
wyciwyg: URI scheme. In other cases, identifiers are not available but
may be desirable, as for many or even most mobile application UI
states. These are open or unencapsulated AUCs. There are also closed
or encapsulated AUCs for which disambiguated identifiers are not
desirable, such as XML namespaces and XML Schema datatypes.

The characteristics of AUCs raise several sub-issues, including:

* Should new URI schemes be made for new AUCs? If not, is separate
application interface chrome (e.g. "View Source" menu item instead of
view-source:) an acceptable alternative? Are there other alternatives?
Is this true for all AUCs or only some? If only some, what are the
characteristics of the subset?
* Given that view-source: coerces resources to text/plain, what
considerations are there for potential AUCIDs that coerce GET to POST,
or change other request parameters such as the User-Agent string?
Should such AUCIDs exist? And, especially, what are their security
implications?
* Should non-browser mobile apps have linkable AUCs? Would this be
sufficient to bring mobile apps to the web, or are further measures
required? If further measures are required, how does this bear on AUCs
in general?
* Is there any difference between use cases such as wanting to coerce
a media-type, and wanting to link to a specific kind of AUC in a
mobile app?
* If different web service tools and native applications use URIs in
different ways, are there any best practices for informing the user
about such variety of usage? Are such best practices different for web
services than for native applications?
* Given that a web service validator could validate an entire domain
and provide a report, is this report to be considered an AUC of the
domain URI, or of the domain as a separate entity abstracted from any
specific URI?
* Some single-page applications use URI fragments to identify AUCs.
Could fragments be deployed more widely, e.g. in non-HTTP URI schemes,
to identify AUCs? What are the drawbacks and advantages between URI
schemes and URI fragments for identifying AUCs?
* Since AUCs can be mixed or blended, such as with plugins in browsers
or viewers for compound formats, should AUCIDs also be composable?
Should there be a new identifier format for AUCIDs analogous but not
the same as URI schemes and fragments?
* Are vendor specific AUCIDs to be treated differently in any respects
to non-vendor specific AUCIDs?
* Is it acceptable for a URI to be used simultaneously in more than
one non-browser URI context? For example, can a URI be used as both an
XML namespace and an XML Schema datatype without drawbacks?
* Should further closed or encapsulated AUCs and AUCID spaces be
created? What are the best practices for such creation? Should they
all use URIs?
* What is the relation between the various closed or encapsulated AUCID spaces?
* Are RDF literal datatypes an instance of closed or encapsulated
AUCIDs? Do the rules for RDF types as specified in httpRange-14 differ
from those of RDF datatypes? Either way, why do they differ from the
rest of the closed or encapsulated AUCIDs, e.g. RDDL relations and
XLink roles, where these rules do not apply?
* There have been attempts to provide separate AUCID spaces to closed
or encapsulated AUCs, such as David Orchard's "id:" URI scheme
proposal for XML namespaces. Such attempts are generally considered
not to be useful. Why not? And do such considerations help to clarify
the distinction between encapsulated and unencapsulated AUCs?
* What should closed or encapsulated AUCIDs return when dereferenced?
The TAG recommends RDDL or GRDDL for XML Namespaces, but has not
pronounced on the issue of XML Schema datatypes or RDDL natures, for
example.
* Are there disadvantages to using a URI simultaneously in more than
one non-browser AUC? Is the browser AUC privileged in any way?
* What should an application do if an external application is not
available to handle a particular URI? For example, if no email client
is available to handle a mailto: address, is there a useful
alternative in the browser? How should such cases be handled more
generally across all AUCs?

Related issues:

* metadataInURI-31 - Related only if information about AUCs can be
considered metadata. (If this is so, can the domain and path also be
considered metadata?) The TAG's finding on this issue does not bear in
any way on the issue of AUCs.
* rdfURIMeaning-39 - Related to the set of closed or encapsulated AUCs.
* schemeProtocols-49 - This issue leads to the related question of how
tightly bound a protocol is to an AUC. In some respects, the concept
of an AUC may be a better fit for URI schemes than protocols.
* genericResources-53 - This is an example of an AUC, and currently
the most important AUC from the point of view of web architecture. The
TAG's finding on this issue ought to specify that a generic resource
is defined by an AUC.
* HttpRedirections-57 - One interpretation of this issue from an AUC
point of view is that URIs in data mix two AUCs: the HTTP web browser
AUC (to be defined by genericResources-53), and the SW browser AUC.
These AUCs may be mixed or blended, i.e. having overlapping contexts,
which creates the conflict in this issue. This is, therefore, a mixed
AUC issue. Disambiguation of one or the other could have been
considered as a design requirement, but this requirement was unknown
when all existing URI in data languages were created.
* webApplicationState-60 - This can now be recast as considering best
practices for the design of URIs to identify specifically JavaScript
web application AUCs. (Note that JavaScript web application AUCs are
not discussed or included in the present message.)
* uriBasedPackageAccess-61 - This is another kind of AUC, this time
concentrating on archived data. (Note again this AUC is not discussed
or included in the present message.)

There are also a number of XML issues, especially
mixedNamespaceMeaning-13 and mixedUIXMLNamespace-33, which are marked
as CLOSED or POSTPONED but for which there is no obvious resolution or
current status documentation. These may also bear on AUCs: an XML
namespace may be considered to identify a format, which has an
arbitrary number of associated AUCs. When the formats are mixed, as
under consideration in Issue 33, the AUCs could also be mixed. Compare
the mixed AUC issues mentioned above.

Exploration of the conceptual space opened up by AUCs and AUCIDs may
lead to a number of important web architecture findings. The suggested
identifier for this issue in the TAG's issue tracker is
"identifyingAUCs-NN", where the number NN is expected to be 69.

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Monday, 3 November 2014 11:26:12 UTC