OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: the simple case and the regrep tech spec

Jon wrote:

| (Folks, please note the cross-posting for this discussion.)

And note that if you're not subscribed to the list you post
to, your message will bounce (to me, in the case of regrep).

| I'm still trying to understand Terry's message of 11 March under
| this subject heading.  I have some questions for him.
| The normative case for what the xml.org implementors are calling a
| "system download" is one in which a document (a purchase order,
| say) used in a machine-mediated transaction references a schema,
| and an application attempting to process the document wants to get
| that schema without human intervention in order to validate the
| document against that schema.  This is the bare minimum of
| functionality as I understand it.

That's one scenario (1B in our list); the same interface can be
used for other purposes; but yes.

| Assuming that the application knows how to handle whatever form of
| schema it finds when it retrieves the thing, there is a question
| of what to do when the schema is actually a composite of several
| modules, as in the case of DocBook.


| >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).  

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.

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".

The relevant list is in data-element-association-list.ent, which is
a mere starter set I made up, with some suggestions from others:

	| uses-comaintained
	| used-by
	| supersedes
	| superseded-by
	| distributed-within

where "uses-comaintained" is the relationship (sorry, association-type)
I assigned to the modules of Docbook in the db1.txt file, which is
the metadata for docbook.dtd.  I wanted to distinguish between
modules that you could count on being present because they're 
maintained by the same SO (or MO) and dependencies on modules maintained
by others, which might disappear without notice ("uses-exterior").
I'm not happy with these names, but those are, I think, the concepts
you want; they probably need sharpening.

regards, Terry

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC