RE: URIs and information typing

[Jonathan Borden <jborden@mediaone.net>]

Henry S. Thompson wrote:
>
> syntax:
> 1) If it ain't broke, don't fix it -- I'm no knee-jerk fan of
> terseness, but requiring fully explicitly qualified names everywhere
> you need to reference one component from another in a schema would be
> a _substantial_ burden on schema authors _and_ schema readers.

to reduce the burden explicitly use qname as a shorthand for the full URI
reference, the syntax remains exactly the same ...

(note: consider defining the attribute "name" as an ID).

>
> architecture:
> 1) It would _require_ dereferencing namespace URIs, something we've
> strenuously avoided in the design to date, for a range of reasons
> including, but not limited to:

why? what would be different than the current system -- the qname could
remain the same. Am I missing something?

>   1a) It would require connectivity or transparent offline-caching;
>   1b) It would introduce network latency as a dominating factor in
>       efficiency;
>   1c) It removes existing flexibility about what is found at the end
>       of namespace URIs -- it's _really_ not up to XML Schema to
>       settle this question.

Just because a URI reference is present doesn't mean it needs to be
dereferenced. Indeed I imagine XML Schema processors would have builtin
knowledge of the meaning of the simple datatypes despite what their URI
references might resolve to. This is the crux of my point, an XML Schema or
RDF application might use a QName, an XLink application might use a URI
reference but they all might interoperate because there would be an
unambiguous mapping of QName <-> URI reference, and this would be entirely
independent of resolution. Of course resolution might yield additional
information and like namespace URIs this would be allowed but not mandated.

>
> 2) It would remove what many of us feel is an important flexibility in
> the design of XML Schema, namely that top-level element, attributes,
> types and identity constraints are in separate 'symbol spaces', that
> is, it's OK to have all of a top-level element, a top-level attribute
> and a type with the same name, something your proposal would rule out.
>

I don't immediately see the utility of this. From perhaps a simplistic
perspective ought a name name one thing regardless of the naming syntax? The
idea of a programming language that allows you to use the same name for a
function and a variable comes to mind. Flexible perhaps, but at what cost in
readability?

-Jonathan