Re: looking for packaging, not a schema (-NOT, counterproposal)

At 08:35 AM 2000-05-18 -0400, Simon St.Laurent wrote:
>At 12:01 PM 5/18/00 +0100, John Aldridge wrote:
>RJ>>  2) it is not the XML Schemas job to say what a NS URI resolves to.
>>
>>This is the crux.  The namespace URI will end up having lots of associated 
>>data.  A schema is one example.  HTML documentation is another.  Come to 
>>that, Schemas Version 2 in a few years time.  The problem of associating 
>>information with a namespace needs a more general solution.
>>
>>This solution, morever, should be catalogue based, not derived from markup 
>>in the document itself.  The fact that a namespace is documented in some 
>>http://whatever file is a property of the namespace, not of the particular 
>>use of the namespace in some XML document.
>
>Doesn't it seem like this kind of schema referencing is a job for the
>never-quite-started XML Packaging activity?  
>

That idea was the presumptive excuse for launching an exploratory packaging
activity earlier, but it did not pan out.  Please consult Noah Mendelsson
if the following recapitulation of the logic is not clear. 

Packaging is probably not the path down which to find a solution for this
puzzle, for the kind of reasoning Ray Whitmer raised in his sixth point:

<quote>

6.  It seems unnatural to tie typing information to default path of a part
of a 
hierarchy.  If I needed this type of relative typing, I would want to relate 
types to other types, not necessarily to where the user stuck a collection of 
graphics files.  Relative of types can apparently already be accomplished by 
using entities, which permits the architect to structure the relationships 

rather than forcing them to flow down the hierarchy with the default
locations 
of, for example, graphics files.

<end quote>

Which is to say, there needs to be substantial independence between the way
names and types are managed and the way that parts and wholes of instances
are managed.  The relative URL convention is indeed tied to existing
virtual-packaging practices which leave web documents with embedded
dependencies on addressing relationships between themselves and the peers
they depend on.

>Making namespace URIs point to something as specific as a schema seems like
>a bad idea, especially for those of us who might rather point to an HTML
>document, a DTD, a RELAX schema, or some other description.

You would not be prevented from configuring your genre documentation so.

>
>We've been in this territory before with namespaces (see the XHTML 1.0
>debate), and it seems widely agreed that Namespaces+Schemas is inadequate
>at best, pernicious at worst.  Where's packaging?
>

Yes we have been around on much of this then.  I am not that sure about
this "widely agreed" claim.  Particularly since there is evidently no
general agreement on what the term 'schemas' would mean in this
proposition.  Schemas means as many different things to different people as
Semantics.

We do need a dual to packaging in the types dimension.  Namespaces is our
principal tool in this regard.  Blending markup flavors is the mission of
Namespaces in XML.  The present recommendation is, by itself, too
semantically lean to fill the shoes of what is really needed.

However, Tim, I still see the best path of action to be to work around
these limitations and move forward in a minimally disruptive fashion.


This is going to take concessions on all sides, probably.  Hopefully I can
sketch a plan here which will appear to the literalists as demanding the
most from them and to the URIists as demanding the most from them...

Leave intact the following two business rules per the straw poll modal
conclusion:

If you want to test a namespace declaration to see if you recognize the
namespace, use the literal namespace attribute value.

If you want to dereference the URI-reference in a namespace attribute
value, follow all rules including absolutization that pertain to URIs as
given in the IETF RFC.

The following may vary somewhat from the territory of straw-poll-supported
decisions:

If you use a relative form of URI-reference in a namespace declaration, you
should be warned that this interferes with the global
(location-independent) usability of the resulting document.

If you encounter a namespace name you _do not_ recognize and you fail to
attempt to recover further guidance by employing the URI-reference as a
dereference key, then you should be warned that you may be missing
information.

A document may in addition to the namespace declaration include other links
or PIs that direct a processor to a schema (broadly or narrowly typed,
according to the reference) location for processing guidance.  The document
so located shall not alter the InfoSet resulting from the parsing of the
current document in any way other than the addition of restrictive
assertions.  In other words, the population of names and their
parse-tree-order indexing shall be stable from the time such processing is
performed using the namespace attribute as an opaque token in constructing
names.  The colloquial interpretation of such a reference shall be "see
e.g." relative to the namespace name declaration.  The processing guidance
document or schema shall also internally bind its assertions to the
namespace name as published (should be what is in the namespace attribute
in the document instance) for the namespace at hand.

This is a rough sketch, but the path to harmony is through looking at the
life cycle of the infoset and determining what properties in the infoset
are reliably determinable without recourse to anything but the opaque value
of the namespace name, and what properties may properly be refined beyond
that point if one additionally applies some processing guidance reachable
with the namespace URI-reference or a related URI-reference as the handle
by which the recovery or application process is keyed.

I think that we can define a concrete model of partial understanding which
will support Tim's extensibility requirements and simultaneously not
disturb the majority of namespace users who want to treat recognizing the
namespace as a "y'know" opaque grunt.  That is to say we can, if we look at
progressive refinement of the knowledge attached to or intrinsic to (you
pick nomenclature) the infoset.

Al





>Simon St.Laurent
>XML Elements of Style / XML: A Primer, 2nd Ed.
>Building XML Applications
>Inside XML DTDs: Scientific and Technical
>Cookies / Sharing Bandwidth
>http://www.simonstl.com
>

Received on Thursday, 18 May 2000 10:09:06 UTC