No subject

[Charles Reitzel]

James Clark wrote:

>>Charles Reitzel wrote:
>> Namespaces are an inherently global construct and I can see no 
>> reason why document writers cannot live with a single prefix 
>> per global identifier within a document.
>
> See http://www.w3.org/TR/NOTE-webarch-extlang#Local for 
> some reasons.

Thanks for the pointer.  It is just what I had been looking for.  I read the
section you referenced, and have given the reasons a good deal of thought,
but I cannot agree with the premises put forward.  Knowing in advance what
namespaces will be combined in a document does not prevent tractable (I
submit, better) solutions to each of the three problems mentioned.

Before addressing each case, I think I have found an underlying difference
in how folks view the namespace prefix.  One camp sees the prefix being
defined *by* the DTD and therefore as a global identifier itself.  The other
camp wants to define the prefix *for* a DTD and, thus, only within a
document.  Specifically, if the namespace is set as a #FIXED attribute for
an element in the DTD, then prefix collision is likely (unless the entire
global ID is used as a prefix). This is an inherent shortcoming of the
prefix notation and inhibits DTD reuse.

IMHO, a more useful approach for most developers is as I posted (based on
others' previous posts): prior to "including" each DTD, set the default
namespace.  The objective is to associate a DTD with that namespace without
changing the DTD.  Perhaps a new syntax is needed to make this association
explicit.  An analogy might be using VMS logical names or Unix environment
variables (e.g. $DATAHOME=//Host/Dir/Sub") to point to a resource that can
move or change.

David Megginson wrote:
>Some people imagine that parts of large XML documents will be
>constructed by many subprocesses spawned by a master process. These
>subprocesses may need to declare and use their own namespaces -- the
>thinking is that it would be unacceptable to require them to
>communicate with the master process to negotiate a
>namespace-declaration and prefix, so they must be able to declare
>namespaces that are applicable only to the fragments under their
>control.

Thanks for the explanation.  I have trouble understanding this concept.  It
sounds a bit like adding a chapter to the book but leaving it out of the
table of contents.

The three cases laid out in the "Extensible Documents" note referenced above
are:

a)      legacy documents (the CGI example)
b)      Long documents
c)      Document concatenation

The short answer to each of these "requirements" is for the author of the
composite document type to create wrapper elements.  This is analogous to
the programming practice of hiding 3rd party library calls within a thin,
locally defined layer of function calls.  Thus, allowing the application to
(more easily) substitute the external resource should the need arise.

a)      legacy documents (the CGI example)

One should be able to declare, in the DTD, the element types used by such
sub-document and associate each with its global namespace id and a locally
unique prefix.  Where validation is not used, simply wrap the legacy
elements within a wrapper element that uses a declared namespace prefix.
All child-elements then default to that namespace - no fuss, no muss.

b)      Long documents

If a document is truly huge, a few namespace declarations at the top are the
least of your worries.  Certainly, the example of a new namespace for each
paragraph is degenerate and should not be the basis for design.  As for
"working set" size (i.e. per process memory), I submit that normalizing the
namespace declarations (i.e. once each at the top of the document) can make
the space cost of namespaces much less.  Each element that belongs to a
different namespace than its parent need only concatenate the local prefix
to its name and not re-declare the global identifier.  Say a large document
has ~100K elements.  Wouldn't it be a misuse of namespaces if the number of
unique global namespace id's was more than ~1K?  Thus, we have just
eliminated the text of the 99% redundant global identifiers.

If one is seriously constrained, break up the document and link the
separately parsed parts (as David M. and others have suggested).  Again, the
extreme case should not be used as a basis for design.  Optimize the typical
case; allow the odd case.

c)      Document concatenation

Why is it inherently desireable to concatenate arbitrary XML documents?
Certainly real applications will construct complete documents from prepared
fragments (after all, this is one of the primary motivations for
namespaces).  But any arbitrary documents?  Is this a pressing concern to
any prospective XML implementers?  If you must concatentate, simply create a
wrapper element.

===

I may be all wet on this stuff.  Really, the only way to make good decisions
about these things is to use real-world examples.  Has anyone compiled a set
of "use cases" to validate prospective xml designs?  The two main ones I
keep hearing about are complex content publishing (one document, many output
media) and ECommerce/EDI. What are some others?

Charlie

P.S. The XSL WD looks excellent.  I need to study it more before I can
appreciate the details (pattern matching!).  The basic transform/render
architecture is real clean and will make XSL useful for many non-visual
applications (generate UN/EDITFACT from XML/EDIFACT!).  The requirements doc
was very helpful.  Anyway, I look forward to using XSL.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)