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

At 10:19 AM 5/18/00 -0500, Al Gilman wrote:
>>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. 

It's not clear _at all_.  Can Noah actually speak, or is he bound by W3C
confidentiality?

>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 for which I see no relevance]

>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.

Er - okay.  We use relative URLs to point to images, DTDs, included
entities, etc. I don't think that's packaging, unless the document itself
is considered its own package.

>>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.

What?  'not be prevented from configuring your genre documentation so'?

What does that mean?  I can do whatever I like with namespace URIs,
provided that I don't assume anyone else is thinking the same way?

>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.

Yes, but that variety of different things directly generates a need for
some kind of indirection, so we can at least point to _something_ in common.

>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.

A 'dual to packaging'?  Sorry, don't follow.

>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.

I think at this point I'd better go get some coffee.  Please remember that
this is a public list, and that some of here haven't been in on the entire
discussion.


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:22:04 UTC