Re: [gutvol-d] barriers to XML posting
----- Original Message ----- From: Marcello Perathoner <marcello@perathoner.de>
Joshua Hutchinson wrote:
Hmm... Maybe I misunderstand here. If a file comes in, marked up in TEI-Lite and we cannot transform it with our standard process, it seems to me either the DTD we've chosen is incomplete or the TEI markup has a bug.
Consider following examples.
A DTD-based validator can catch this:
<address> <date>01 Jan 2004</date> </address>
because a date has no business inside an address.
But not this:
<address> <name>Chicago</name> <street>2830 North Clark</street> <place>Curl Up and Dye Beauty Salon</place> </address>
The validator cannot know that the markup is all wrong. Of course this will _transform_ all right.
Ok, I am learning here, honest. But here's another dumb question in the meantime. Shouldn't a TEI-Lite validator flag your second example as wrong, too? Looking over the TEI-Lite documentation, you could markup that information, but in a slightly different format. <address> <addrLine><name type="city">Chicago</name></addrLine> <addrLine><name type="street">2830 North Clark</name></addrLine> <addrLine><name type="place">Curl Up and Dye Beauty Salon</name></addrLine> <address> Now, putting aside the fact that I doubt I'd ever bother to mark up an address to that exacting of a detail ;) ... Am I understanding the role of the validator properly in that it should choke on the first, since it doesn't, as far as I can tell, conform to TEI-Lite?
No. All you can define inside an XML file is the DTD (or other schema) you want to use and entities like &myentity;
Of course you can use a DTD that defines some stuff and then includes the standard TEI DTD. But, as said above, there is a better way to do that in TEI.
That seems acceptable to me. For instance, to continue you example above, if you wanted to add <place>, <name>, and <street> to the <address> markup, then you could put those elements in your personally DTD, which calls the TEI-Lite DTD, and then the validator should be able to parse it as acceptable code, right? But the question then becomes, will the standard transform be able to handle the new code in your DTD? If it just ignores what it doesn't understand, that would be acceptable, I'd think. But if the new tags cause the transform to choke, then we'd have a problem. Josh
Joshua Hutchinson wrote:
Shouldn't a TEI-Lite validator flag your second example as wrong, too? Looking over the TEI-Lite documentation, you could markup that information, but in a slightly different format.
That was just a general example. It was not meant to be specific to TEI.
Now, putting aside the fact that I doubt I'd ever bother to mark up an address to that exacting of a detail ;) ... Am I understanding the role of the validator properly in that it should choke on the first, since it doesn't, as far as I can tell, conform to TEI-Lite?
It will choke if you validate my example against the TEI DTD. But I could write a SOMETHING DTD that validates that example all right.
That seems acceptable to me. For instance, to continue you example above, if you wanted to add <place>, <name>, and <street> to the <address> markup, then you could put those elements in your personally DTD, which calls the TEI-Lite DTD, and then the validator should be able to parse it as acceptable code, right?
Yes.
But the question then becomes, will the standard transform be able to handle the new code in your DTD? If it just ignores what it doesn't understand, that would be acceptable, I'd think. But if the new tags cause the transform to choke, then we'd have a problem.
A standard TEI transform will simply ignore all tags he doesn't recognize. Just like a HTML browser does. -- Marcello Perathoner webmaster@gutenberg.org
participants (2)
-
Joshua Hutchinson -
Marcello Perathoner