Some details (was: Re: the simple case and the regrep tech spec)

[Jon Bosak <Jon.Bosak@eng.sun.com>]

[Terry Allen:]

| | >From an initial reading of Terry's message, I get the impression
| | that the submitter in this case has to submit the composite schema
| | needed for automatic validation as a registered item in its own
| | right, even if the separate modules that make it up are also
| | registered items.  Is this correct?
| 
| 
| Not necessarily (although Bill Smith suggested it a year ago in
| Granada, and we might want to do things this way - it just doesn't
| scale very well).

We might want to reconsider this if it has performance implications.

| In the case of Docbook, a parser that started with docbook.dtd
| would encounter references to the other modules and download them
| as they're encountered (I'll bet nsgmls does this correctly,
| although I haven't tested).  As DTDs should be cached for a much
| longer period than random files encountered on the Web, the first
| use of Docbook should load the application's cache with all the
| required modules, and subsequently all the parts of the DTD would
| be present locally (which is how we use Docbook today).
| 
| If you recall using Panorama to parse a TEI document, you'll
| know that successive GETs like this can take a long time,
| depending on the Web weather.

Yes.  In a transaction-oriented b2b environment this should work
pretty well, but it might slow down b2c significantly until we get
really standardized with the forms.  So people may wish to fully
expand the schema and point to it as a single object.  It seems to
me that there might be workflow advantages to tracking a single
file, too.

| If we were to develop an appropriate packaging mechanism, the
| application might download all the modules together, unpack,
| and then start work.  But we don't have that now.
| 
| | If this is not correct, I'm going to guess in advance that there
| | is in theory a way to reconstruct the composite schema from a
| | "specification of relationships among related data."  If this is
| 
| Yep, that's another approach, although I'm not sure what it
| gains you.
| 
| | the case, can there be more than one "specification of
| | relationships among related data," and can there be a standard way
| | of pointing to which "specification of relationships among related
| | data" allows an application in the minimum case correctly to
| | assemble the composite schema?
| 
| Yes, you can specify as many relationships as you like.  For some
| reason the current DTD calls these relationships "associations".

Well, but...

What I mean is can you specify how to assemble the schema in the
right order.  Not in a standard way, it seems (though I can make a
private convention that the order of related-data-references
specifies the order in which modules are to be assembled).

... Sorting this out in a place where I can find it, don't mind
me ...

... Actually, there are comments below for Terry.  I will continue
a response to his original posting on The Simple Case in a
separate message.

Looking at data-element.dtd, we have

   <!ENTITY % data-element-content
	   "data-element-concept,
	   data-element-association-set?,
	   representation,
	   name-context+,
	   (related-data-reference* | related-data-group-reference)"
   >

   [...]

   <!ELEMENT related-data-reference (related-data-reference-label?,
	   (uri-reference))>
   <!ATTLIST related-data-reference
	   relationship-of-related (%related-entity-list;) #REQUIRED
   >

   <!ELEMENT related-data-reference-label (#PCDATA)>

   <!ELEMENT related-data-group (data-element-reference, 
	   related-data-reference+)>

   <!ELEMENT related-data-group-reference (uri-reference)>
   <!ATTLIST related-data-group-reference
	   relationship-of-related CDATA #FIXED "related-data-group" 
   >

>From related-entity-list.ent:

	related-data-group
	| %documentation-genre-list;
	| %other-xsgml-list;
	| %style-sheet-list;
	| schema-home-page
	| distribution-home-page
	| registration-information
	| cover-letter
	| other

documentation-genre-list is:

	documentation-set
	| documentation-set-information
	| reference-manual
	| user-guide
	| white-paper
	| faq
	| example
	| example-set
	| example-set-information
	| changelog
	| readme
	| email-discussion-list-information
	| tool-information

literary-genre-list is:

	book
	| article
	| recipe
	| %documentation-genre-list.ent;

This is backwards from what I would have expected.  From the
inclusion in related-entity-list.ent of %documentation-genre-list
I would have expected documentation-genre-list.ent to import
%literary-genre-list instead of the other way around.

other-xsgml-list is

	sgml-open-catalogue
	| sgml-declaration
	| public-text

xsgml-entity-list.ent is

	xml-dtd
	| sgml-dtd
	| xml-schema
	| xdr-schema
	| sox-schema
	| rdf-schema
	| sgml-element
	| xml-element
	| sgml-attribute
	| xml-attribute
	| sgml-enumerated-attribute-set
	| xml-enumerated-attribute-set
	| sgml-enumerated-attribute-value
	| xml-enumerated-attribute-value
	| sgml-parameter-entity
	| xml-parameter-entity
	| character-entity-set

Shouldn't relax-schema be in there someplace?

style-sheet-list.ent is:

	style-sheet-information
	| xsl-style-sheet
	| xsl-style-sheet-information
	| dsssl-style-sheet
	| dsssl-style-sheet-information

Which I think exhausts the categories of things that can be
related via a related-data-reference to a registered data item;
right?

Jon