Re: Thoughts on namespaces--Several active within one element, No DTD changes.

Andrew,

<rant>
You say people want to do this without DTDs, so let's look at what DTDs are
for. From my perspective as an application designer, a DTD defines a class of
data structures, and a document is a member of that class.  The DTD acts as the
"contract" between the document author and the application.  Would these same
people write C code without using any structs, and have to infer the structure
of bytes by hand?  People who are used to browsers may not understand this,
because there are two information exchanges going on - between the author and
the reader (which, since it involves humans, can be very freeform), and between
the document and browser.  Since I am interested in replacing the human in the
first instance by an application and not terribly interested in browsers, I
need some kind of contract to know the structure of the information I am
getting.  Well-formedness just doesn't cut it for this.
</rant>

I'm still trying to get my head around the namespace issue.  As I see it, my
application will be handed an expanded tree.  Embedded in that tree are various
trees, one of which corresponds to a data structure I can understand.  So the
question for me is, do namespaces properly convey to my application what that
embedding is - preferably without my writing any additional code.  Does this
make sense?

Also, since there will now possibly be several simultaneous views of the same
tree, how do the different aspects communicate - i.e., if I have one module
that understands cars, and another that understands digital signatures, how do
they communicate about common parts of the tree.  In this case, how do I know
the scope of the digital signature?

As an aside, if I get this right, the prefixes are partially a means of alpha
renaming GIs to avoid aliasing.  This is important.

On May 22,  2:02pm, Andrew Layman wrote:
> Subject: RE: Thoughts on namespaces--Several active within one element, No
> At 04:30 PM 5/22/97 GMT, Christopher R. Maden wrote:
>
> >First, I believe the primary goal of namespaces is to allow borrowing
> >of established semantics - I want to use TEI's <xref>, HTML's <a>, and
> >the FAQ DTD's <q> and <a>.
>
> This is true, but does not completely explain the requirement. Let me
> elaborate on it.  What my customers are telling me is that they want to
> be able to take an element that exists already, defined in some
> namespace, then add sub-elements from other namespaces. Using the
> proposed namespace qualification operator, I can illustrate this as:
>
> <CAR>
> 	<SEATS>6</SEATS>
> 	<ENGINE>
> 		<CYLINDERS>6</CYLINDERS><DISPLACEMENT>4</DISPLACEMENT>
> 	</ENGINE>
> 	<a:COLOR>LIGHT CORAL<a:COLOR>
> 	<b:DSIG><SUM>123456</SUM><WHO>Andrew</WHO></b:DSIG>
> 	<BUYER>
> 		<ssa:SSN>123456789</ssa:SSN>
> 		<tei:XREF>http://ssa.gov</tei:XREF>
> 	</BUYER>
> </CAR>
>
> This has five namespaces running within CAR: The one from which CAR
> comes, and also "a", "b", "ssa" and "tei".
>
> They want to do this without requiring that any DTD's are modified.
> (Frankly, they want to do this without any DTDs at all.)
>
> Why? Because these people are in one way or another annotating
> documents, or accumulating various bits of information together, where
> some of the information comes from one domain and some from another. The
> digital signature, for example, comes from the world of security
> information, and will be read by some selected applications (such as
> firewalls). Naturally, finding every document that might ever need to
> have a digital signature and updating its DTD would be an impossibly
> expensive task. In many case, it would be completely impractical,
> because an author of a document might not have write privileges on the
> DTD.  Different users, from different applications, will want to
> annotate elements with subelements from differing namespaces.
>
> So, it is not enough to be able to say at the beginning of my document
> that there are such things as COLOR, DSIG, SSN and XREF, all from
> different namespaces. I also need to make each of these usable within
> CAR, without modifying any DTD.
>
>
>
>
>-- End of excerpt from Andrew Layman



--

Received on Thursday, 22 May 1997 19:56:59 UTC