Namespaces, Architectural Forms, and Sub-Documents

[Martin Bryan]

>It seems to me that when you want to embed large contiguous structures
>from different document types in an XML document, each different
>namespace should be its own sub-document, referenced as a binary
>entity (or using whatever other mechanisms are available in XML-Link).


I'm interested in the concept of using links to datasets that are to be
embedded into other documents as 'subdocument modules'. When the linked data
is embedded it becomes a part of the document tree (you want queries and
locations to count the embedded elements). But it could have namespace/model
clashes so you want each linked sequence treated as a module with its own
name space. (A subdocument is not possible as there is no guarantee the
linked material will form a valid/complete document.)
>
>Good tools and protocols should make it possible to create, transmit,
>and process compound documents as if they were single files.  This
>will be necessary anyway for supporting multimedia.

I'm not convinced that all compound documents will be supportable with a
single document structure. This seems especially true of multimedia sets
created using cut & paste type operations.

>Here are some general guidelines:
>
>* Architectural forms are most suitable for applications where
>  multiple inheritance is required, or where elements belonging to a
>  different document type are scattered throughout a document.
>
>* Sub-documents are most suitable for applications where all of the
>  element belonging to a different document type are rooted in a
>  single subtree.

Providing the subtree is complete: this is not necessarily true of spans
>
>"namespace:gi" element type names are unsuitable for several reasons:
>
>1) The complexity of namespaces is exposed to the author rather than
>   hidden in the DTD (as it is, optionally, with architectural forms).
>
>2) Multiple inheritance is not possible (X can be a kind of Y or a
>   kind of Z, but not both).
>
>3) Standard DTD-based validation is not possible, and it is more
>   difficult to create DTD-driven authoring tools.
>
>4) Both architectural forms and sub-documents can be fully supported
>   under the existing spec by _both_ validating and non-validating XML
>   parsers: no changes necessary.  Furthermore, they will also remain
>   compatible with SGML tools.
>
>Why are people worried about writing specs to solve a problem that
>already has good, working, available solutions?

Unfortunately subdocs are not supported in XML, or in many SGML tools. If
you look at Charles Goldfarb's proposals for module naming in the light of
subdocs it is interesting that the module name becomes the name of the
entity that is used to reference the subdoc in the referencing file. This
ensures that the subdocument module name is unique in every context, because
the entity calling it must be uniquely named.

Martin Bryan


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)