Re: How to get the 1st element in DTDD

[Murali Mani <mani@CS.UCLA.EDU>]

On Sat, 23 Jun 2001, Marcus Carr wrote:

> Sure - you may have numerous authors working on a single document.
> They may each be writing a chapter, then the book will be validated in
> it's entirety.
>
> Another example - the tool of choice for many markup people is a text
> editor, but when it comes to tables, they often prefer to use an
> editor that provides visual support. (CALS syntax is doable but
> difficult without.) External entities are used to provide a
> placeholder for the table markup in the main document and the tables
> are created and validated independently. The final step is a
> normalisation of the document, generally (but not necessarily) pulling
> everything into one file.

Yes, the schema should allow evolution -- does not this work?? -- allow
changing type definitions and modification of the possible set of root
elements, by adding new root elements -- the modules of RELAX and combine
them using include and then add new root elements by having new interface
element -- they add on to the existing root elements declared in the old
interface element -- I am not very sure, but I think such document
evolution should be the reason why RELAX is designed such.

> These are real-world examples - we have been doing both as standard
> practice for ten years. Limiting the root elements would diminish the
> effectiveness of data creators. I'm guessing that you feel there are
> downstream processes that would benefit from limiting the set of
> possible root elements - if so, could you explain what they might be
> and how they would benefit?

I deal with data after they are created -- for query purposes (possibly
updates later on) -- I cluster documents based on the root -- for example
if someone asks for //book/author I might not search in the documents
whose root is say AutomobileStore, rather I might look among the documents
whose root is only Library -- note that when I store, I do not actually
allow a set of possible root elements -- it is more stringent -- only one
root element -- though when we design, we keep the flexibility -- probably
we might need to use this later as some trade-off or something.

regards - murali.