RE: Fwd: Re: [Big-devel] big bad mother schema (was RE: RE: appinfo stuff)

[Ben R. <be...@ca...>]

> -----Original Message-----
> From: big...@li...
> [mailto:big...@li...]On Behalf Of Jim Croft


> > > basically everything that does not fit in the main part of the
> > > element itself...
> >
> >Sorry, but I don't follow your meaning...

> What I was driving at is that there are a number of things in
> our esisting descriptions of  a HISPID element  that are already
> handled by the schema as attributes outside of the
> annotation/documentation/appinfo construct.  Such things as the
> name of the element, a short tag, a bried description, acceptable
> ranges, values, obligation, optionality, repeatability, etc.
>
> These are the things I am suggesting that we may not need to
> repeat in the
> appinfo structured explanatory material.  We could, but it would be
> redundant and maybe get out of sync and lead to confusion.

..and would be a smart way to "re-use" the work spent couching the
"rules" of HISPID5 in a schema.

This is exactly what I was thinking.

> The appinfo should be used to hold constraints, dependencies and
> explanation that we can not express in the working part foteh schema.
> As we move into this new way of expressing HISPID, I think we need
> to shed the traditional HISPID as a book paradigm that we have grown
> used to...

We can, but we don't have to.  We can publish to book via XSLT/FO,
import into databases, etc.  No need to limit ourselves just because
books are a bit passe these days.


> Once we get this first pass finished and validated I would strongly
> recommend that we create an official repository as an on-line
> database that allows shared access and on-line editing...

Done.  It is in CVS, which is a database of sorts..

Cheers,
Ben