This is a tricky one, so please bear with me and read to the end before rolling eyes. In Simple, the only available global attribute for recording rendition is @rendition, which (you will recall) is intended to provide a pointer to a <rendition> element, either in the header or elsewhere. So (simplifying somewhat) you might do <p rendition="#foo"> and somewhere in the header have <rendition xml:id="foo"><!-- some CSS styling here --></rendition> and expect "some CSS styling here" to be applied to your <p> Since life is short and we don't really want to have to say that "foo" means "font-style:italic" in every single document we produce, (thus making it impossible to combine documents, because you will have multiple definitions for "foo" ) you can also use a private URI, like this <p rendition="my:foo"> and then in your header map the prefix "my" to some URL where the <rendition> element concerned is to be found inside a <listPrefixDef> containing something like: <prefixDef ident="my" matchPattern="([A-Z]+)" replacementPattern="http://www.example.com/myListOfStyles.xml#$1"/> So far so good, and that mechanism (which is also very useful eg to link from a <name> to a <person> in a personography) is well attested, reasonably well understood, kosher TEI. Unfortunately, Simple doesn't use it, despite appearances. What Simple does is to define a whole shed load of "suggested values" for @rendition using a valList in the ODD, which begins like this: <valList mode="add" type="semi"> <valItem ident="simple:allcaps"> <desc>all capitals</desc> </valItem> <valItem ident="simple:blackletter"> <desc>black letter or gothic typeface</desc> </valItem> <valItem ident="simple:bold"> <desc>bold typeface</desc> </valItem> <valItem ident="simple:bottombraced"> <desc>marked with a brace under the bottom of the text</desc> </valItem> <valItem ident="simple:boxed"> <desc>border around the text</desc> </valItem> So it *looks* like we are defining a whole shed load of private URIs, hoorah. But nowhere is there a <prefixDef> that tells me what the "simple" prefix means i.e. how to map eg "simple:blackletter" to the appropriate CSS! Nor indeed is it clear where such a beast would reside. Maybe one day the TEI will provide a server from which recognised CSS mappings for these private URIs could be recovered, but I am not holding my breath. So, despite appearances, we have to conclude that these things are not really private URIs at all, but rather MAGIC CODES. In which case, really they ought to be being supplied on a @rend attribute... It gets worse. The current schema includes a schematron constraint which says that the value of @rendition MUST be either a local pointer starting with '#' or a magic code starting "simple:". So I cannot define my own prefixes either. All I can do is provide the missing <prefixDef>s myself, which seems a bit hard on the Simple user. At the moment the documentation is tactfully silent around this issue, or was until I introduced a brief explanation of how prefixDef works. Should I now expand this to spell out that users of Simple are expected to provide their own mappings for such of the proposed @rendition values as they choose to use? Or that Simple just provides these things like that, go figure ? And where should they put their mappings? In the header of the document? But then they might as well be defined locally using xml:id and a regular # pointer (especially since you can't put a colon inside an xml:id value). In some other document we're not going to talk about? (My eyeballs, at least, are now rolling)
Hi Lou, I think you are still misunderstanding the suggestion I made by private email earlier, so let me spell it out more. 1) There is CSS defined for these private URI values at https://github.com/TEIC/TEI/blob/tei-simple/P5/Exemplars/tei_simple.odd#L630... but yes, they aren't in <rendition> statements in the header. 2) I suggest that add a <listPrefixDef> and <prefixDef> into the TEI Simple ODD, as well as appropriate <rendition> elements in the header of the TEI Simple ODD. Thus simple:allcaps would get a rendition of: <rendition xml:id="allcaps">text-transform: uppercase;</rendition> And the <prefixDef> for simple would point to the release version of the TEI Simple ODD and the xml:id after it. e.g. <prefixDef ident="simple" matchPattern="([a-Z]+)" replacementPattern="http://www.tei-c.org/whatever/the/path/is/tei_simple.odd#$1"/> 3) We then also document in prose that the simple: private URI refers to these rendition values in the TEI Simple ODD. This makes sense to me. If I knew nothing about TEI Simple, but knew that it provided these values, then I would go look at the ODD to see what those values meant. I understand you'll object that this TEI Simple prefixDef then needs to be in every Simple document, and indeed we could add it to the oxygen TEI Simple template. Having them defined like this in the ODD makes them a much less worrying form of magic. -James On 29/06/16 14:57, Lou Burnard wrote:
This is a tricky one, so please bear with me and read to the end before rolling eyes.
In Simple, the only available global attribute for recording rendition is @rendition, which (you will recall) is intended to provide a pointer to a <rendition> element, either in the header or elsewhere. So (simplifying somewhat) you might do <p rendition="#foo"> and somewhere in the header have <rendition xml:id="foo"><!-- some CSS styling here --></rendition> and expect "some CSS styling here" to be applied to your <p>
Since life is short and we don't really want to have to say that "foo" means "font-style:italic" in every single document we produce, (thus making it impossible to combine documents, because you will have multiple definitions for "foo" ) you can also use a private URI, like this <p rendition="my:foo"> and then in your header map the prefix "my" to some URL where the <rendition> element concerned is to be found inside a <listPrefixDef> containing something like:
<prefixDef ident="my" matchPattern="([A-Z]+)" replacementPattern="http://www.example.com/myListOfStyles.xml#$1"/>
So far so good, and that mechanism (which is also very useful eg to link from a <name> to a <person> in a personography) is well attested, reasonably well understood, kosher TEI.
Unfortunately, Simple doesn't use it, despite appearances. What Simple does is to define a whole shed load of "suggested values" for @rendition using a valList in the ODD, which begins like this:
<valList mode="add" type="semi"> <valItem ident="simple:allcaps"> <desc>all capitals</desc> </valItem> <valItem ident="simple:blackletter"> <desc>black letter or gothic typeface</desc> </valItem> <valItem ident="simple:bold"> <desc>bold typeface</desc> </valItem> <valItem ident="simple:bottombraced"> <desc>marked with a brace under the bottom of the text</desc> </valItem> <valItem ident="simple:boxed"> <desc>border around the text</desc> </valItem>
So it *looks* like we are defining a whole shed load of private URIs, hoorah. But nowhere is there a <prefixDef> that tells me what the "simple" prefix means i.e. how to map eg "simple:blackletter" to the appropriate CSS! Nor indeed is it clear where such a beast would reside. Maybe one day the TEI will provide a server from which recognised CSS mappings for these private URIs could be recovered, but I am not holding my breath. So, despite appearances, we have to conclude that these things are not really private URIs at all, but rather MAGIC CODES. In which case, really they ought to be being supplied on a @rend attribute...
It gets worse. The current schema includes a schematron constraint which says that the value of @rendition MUST be either a local pointer starting with '#' or a magic code starting "simple:". So I cannot define my own prefixes either. All I can do is provide the missing <prefixDef>s myself, which seems a bit hard on the Simple user.
At the moment the documentation is tactfully silent around this issue, or was until I introduced a brief explanation of how prefixDef works. Should I now expand this to spell out that users of Simple are expected to provide their own mappings for such of the proposed @rendition values as they choose to use? Or that Simple just provides these things like that, go figure ?
And where should they put their mappings? In the header of the document? But then they might as well be defined locally using xml:id and a regular # pointer (especially since you can't put a colon inside an xml:id value). In some other document we're not going to talk about? (My eyeballs, at least, are now rolling)
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Hi James Thanks, yes, you are right in thinking I had missed the definitions (they are right at the end of the file...) and also the nuance that you are proposing we make the Simple ODD itself the vector by which they are transmitted. It's not quite right, since of course the Simple ODD is not itself a Simple-conformant document (and cannot be), but It Just Might Work. L On 29/06/16 16:50, James Cummings wrote:
Hi Lou,
I think you are still misunderstanding the suggestion I made by private email earlier, so let me spell it out more.
1) There is CSS defined for these private URI values at https://github.com/TEIC/TEI/blob/tei-simple/P5/Exemplars/tei_simple.odd#L630... but yes, they aren't in <rendition> statements in the header.
2) I suggest that add a <listPrefixDef> and <prefixDef> into the TEI Simple ODD, as well as appropriate <rendition> elements in the header of the TEI Simple ODD. Thus simple:allcaps would get a rendition of:
<rendition xml:id="allcaps">text-transform: uppercase;</rendition>
And the <prefixDef> for simple would point to the release version of the TEI Simple ODD and the xml:id after it. e.g. <prefixDef ident="simple" matchPattern="([a-Z]+)" replacementPattern="http://www.tei-c.org/whatever/the/path/is/tei_simple.odd#$1"/>
3) We then also document in prose that the simple: private URI refers to these rendition values in the TEI Simple ODD.
This makes sense to me. If I knew nothing about TEI Simple, but knew that it provided these values, then I would go look at the ODD to see what those values meant.
I understand you'll object that this TEI Simple prefixDef then needs to be in every Simple document, and indeed we could add it to the oxygen TEI Simple template. Having them defined like this in the ODD makes them a much less worrying form of magic.
-James
On 29/06/16 14:57, Lou Burnard wrote:
This is a tricky one, so please bear with me and read to the end before rolling eyes.
In Simple, the only available global attribute for recording rendition is @rendition, which (you will recall) is intended to provide a pointer to a <rendition> element, either in the header or elsewhere. So (simplifying somewhat) you might do <p rendition="#foo"> and somewhere in the header have <rendition xml:id="foo"><!-- some CSS styling here --></rendition> and expect "some CSS styling here" to be applied to your <p>
Since life is short and we don't really want to have to say that "foo" means "font-style:italic" in every single document we produce, (thus making it impossible to combine documents, because you will have multiple definitions for "foo" ) you can also use a private URI, like this <p rendition="my:foo"> and then in your header map the prefix "my" to some URL where the <rendition> element concerned is to be found inside a <listPrefixDef> containing something like:
<prefixDef ident="my" matchPattern="([A-Z]+)" replacementPattern="http://www.example.com/myListOfStyles.xml#$1"/>
So far so good, and that mechanism (which is also very useful eg to link from a <name> to a <person> in a personography) is well attested, reasonably well understood, kosher TEI.
Unfortunately, Simple doesn't use it, despite appearances. What Simple does is to define a whole shed load of "suggested values" for @rendition using a valList in the ODD, which begins like this:
<valList mode="add" type="semi"> <valItem ident="simple:allcaps"> <desc>all capitals</desc> </valItem> <valItem ident="simple:blackletter"> <desc>black letter or gothic typeface</desc> </valItem> <valItem ident="simple:bold"> <desc>bold typeface</desc> </valItem> <valItem ident="simple:bottombraced"> <desc>marked with a brace under the bottom of the text</desc> </valItem> <valItem ident="simple:boxed"> <desc>border around the text</desc> </valItem>
So it *looks* like we are defining a whole shed load of private URIs, hoorah. But nowhere is there a <prefixDef> that tells me what the "simple" prefix means i.e. how to map eg "simple:blackletter" to the appropriate CSS! Nor indeed is it clear where such a beast would reside. Maybe one day the TEI will provide a server from which recognised CSS mappings for these private URIs could be recovered, but I am not holding my breath. So, despite appearances, we have to conclude that these things are not really private URIs at all, but rather MAGIC CODES. In which case, really they ought to be being supplied on a @rend attribute...
It gets worse. The current schema includes a schematron constraint which says that the value of @rendition MUST be either a local pointer starting with '#' or a magic code starting "simple:". So I cannot define my own prefixes either. All I can do is provide the missing <prefixDef>s myself, which seems a bit hard on the Simple user.
At the moment the documentation is tactfully silent around this issue, or was until I introduced a brief explanation of how prefixDef works. Should I now expand this to spell out that users of Simple are expected to provide their own mappings for such of the proposed @rendition values as they choose to use? Or that Simple just provides these things like that, go figure ?
And where should they put their mappings? In the header of the document? But then they might as well be defined locally using xml:id and a regular # pointer (especially since you can't put a colon inside an xml:id value). In some other document we're not going to talk about? (My eyeballs, at least, are now rolling)
Hi Lou, Yes, that is the slight fudge I was referring to. The simple: prefix _should_ really be defined in a local document instance. It is just because it is simple: that someone would know to go to look in the Simple ODD if we don't define it locally. I think you can define renditions in any document instance for any prefix, so don't have a problem with the ODD defining simple: prefixes, it is just a shame they aren't magically in the instance document. My suggestion is that we ensure that the template file also has this prefixDef in it (with the full URI). But other than than I'm fairly comfortable with it as a solution, and you know I don't like magic. Oh, I realised I glossed over another comment you'd had. Yes. I think that the original intent of the schema was that it would only allow simple:* and #* as values of rendition. i.e., as you note I couldn't do jamesc:* Given the expanded role some are planning for simple, we could do two things: a) stick with the original, if you aren't using simple:* or #* then what you are doing isn't _simple_ so you should define your own ODD or b) enable you to have your own private URI prefixes and define a schematron rule to warn when a-Z:* doesn't have a matching rendition/@xml:id. Either of these sticks with the original intent, I think, to stop people putting 'b', 'bold', 'boldface', 'bold-text', 'bld' and to standardise through making doing it another way more difficult. (i.e. defining your own renditions) -James On 29/06/16 16:57, Lou Burnard wrote:
Hi James
Thanks, yes, you are right in thinking I had missed the definitions (they are right at the end of the file...) and also the nuance that you are proposing we make the Simple ODD itself the vector by which they are transmitted. It's not quite right, since of course the Simple ODD is not itself a Simple-conformant document (and cannot be), but It Just Might Work.
L
On 29/06/16 16:50, James Cummings wrote:
Hi Lou,
I think you are still misunderstanding the suggestion I made by private email earlier, so let me spell it out more.
1) There is CSS defined for these private URI values at https://github.com/TEIC/TEI/blob/tei-simple/P5/Exemplars/tei_simple.odd#L630... but yes, they aren't in <rendition> statements in the header.
2) I suggest that add a <listPrefixDef> and <prefixDef> into the TEI Simple ODD, as well as appropriate <rendition> elements in the header of the TEI Simple ODD. Thus simple:allcaps would get a rendition of:
<rendition xml:id="allcaps">text-transform: uppercase;</rendition>
And the <prefixDef> for simple would point to the release version of the TEI Simple ODD and the xml:id after it. e.g. <prefixDef ident="simple" matchPattern="([a-Z]+)" replacementPattern="http://www.tei-c.org/whatever/the/path/is/tei_simple.odd#$1"/>
3) We then also document in prose that the simple: private URI refers to these rendition values in the TEI Simple ODD.
This makes sense to me. If I knew nothing about TEI Simple, but knew that it provided these values, then I would go look at the ODD to see what those values meant.
I understand you'll object that this TEI Simple prefixDef then needs to be in every Simple document, and indeed we could add it to the oxygen TEI Simple template. Having them defined like this in the ODD makes them a much less worrying form of magic.
-James
On 29/06/16 14:57, Lou Burnard wrote:
This is a tricky one, so please bear with me and read to the end before rolling eyes.
In Simple, the only available global attribute for recording rendition is @rendition, which (you will recall) is intended to provide a pointer to a <rendition> element, either in the header or elsewhere. So (simplifying somewhat) you might do <p rendition="#foo"> and somewhere in the header have <rendition xml:id="foo"><!-- some CSS styling here --></rendition> and expect "some CSS styling here" to be applied to your <p>
Since life is short and we don't really want to have to say that "foo" means "font-style:italic" in every single document we produce, (thus making it impossible to combine documents, because you will have multiple definitions for "foo" ) you can also use a private URI, like this <p rendition="my:foo"> and then in your header map the prefix "my" to some URL where the <rendition> element concerned is to be found inside a <listPrefixDef> containing something like:
<prefixDef ident="my" matchPattern="([A-Z]+)" replacementPattern="http://www.example.com/myListOfStyles.xml#$1"/>
So far so good, and that mechanism (which is also very useful eg to link from a <name> to a <person> in a personography) is well attested, reasonably well understood, kosher TEI.
Unfortunately, Simple doesn't use it, despite appearances. What Simple does is to define a whole shed load of "suggested values" for @rendition using a valList in the ODD, which begins like this:
<valList mode="add" type="semi"> <valItem ident="simple:allcaps"> <desc>all capitals</desc> </valItem> <valItem ident="simple:blackletter"> <desc>black letter or gothic typeface</desc> </valItem> <valItem ident="simple:bold"> <desc>bold typeface</desc> </valItem> <valItem ident="simple:bottombraced"> <desc>marked with a brace under the bottom of the text</desc> </valItem> <valItem ident="simple:boxed"> <desc>border around the text</desc> </valItem>
So it *looks* like we are defining a whole shed load of private URIs, hoorah. But nowhere is there a <prefixDef> that tells me what the "simple" prefix means i.e. how to map eg "simple:blackletter" to the appropriate CSS! Nor indeed is it clear where such a beast would reside. Maybe one day the TEI will provide a server from which recognised CSS mappings for these private URIs could be recovered, but I am not holding my breath. So, despite appearances, we have to conclude that these things are not really private URIs at all, but rather MAGIC CODES. In which case, really they ought to be being supplied on a @rend attribute...
It gets worse. The current schema includes a schematron constraint which says that the value of @rendition MUST be either a local pointer starting with '#' or a magic code starting "simple:". So I cannot define my own prefixes either. All I can do is provide the missing <prefixDef>s myself, which seems a bit hard on the Simple user.
At the moment the documentation is tactfully silent around this issue, or was until I introduced a brief explanation of how prefixDef works. Should I now expand this to spell out that users of Simple are expected to provide their own mappings for such of the proposed @rendition values as they choose to use? Or that Simple just provides these things like that, go figure ?
And where should they put their mappings? In the header of the document? But then they might as well be defined locally using xml:id and a regular # pointer (especially since you can't put a colon inside an xml:id value). In some other document we're not going to talk about? (My eyeballs, at least, are now rolling)
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Thanks to James' intervention this one turned out to be simple (ha) enough. I've added the valList into the teiHeader of the simple ODD document itself. This means that a simple document wishing to say e.g. <p rendition="simple:bold"> can do so iff it includes in its header a prefixDef element associating "simple" with the TEI Simple ODD. Which in turn means we should decide on a canonical web location for same, so that the document can tell people how to do it. How about www.tei-c.org/Simple/tei_simple.odd ? Pointing, of course, to http://www.tei-c.org/release/xml/tei/Exemplars/tei_simple.odd Setting up a directory Simple on the website would also give us a place to park background information about Simple, what is XML, the history of the project, and other stuff I have ruthlessly purged. On 29/06/16 15:57, Lou Burnard wrote:
This is a tricky one, so please bear with me and read to the end before rolling eyes.
In Simple, the only available global attribute for recording rendition is @rendition, which (you will recall) is intended to provide a pointer to a <rendition> element, either in the header or elsewhere. So (simplifying somewhat) you might do <p rendition="#foo"> and somewhere in the header have <rendition xml:id="foo"><!-- some CSS styling here --></rendition> and expect "some CSS styling here" to be applied to your <p>
Since life is short and we don't really want to have to say that "foo" means "font-style:italic" in every single document we produce, (thus making it impossible to combine documents, because you will have multiple definitions for "foo" ) you can also use a private URI, like this <p rendition="my:foo"> and then in your header map the prefix "my" to some URL where the <rendition> element concerned is to be found inside a <listPrefixDef> containing something like:
<prefixDef ident="my" matchPattern="([A-Z]+)" replacementPattern="http://www.example.com/myListOfStyles.xml#$1"/>
So far so good, and that mechanism (which is also very useful eg to link from a <name> to a <person> in a personography) is well attested, reasonably well understood, kosher TEI.
Unfortunately, Simple doesn't use it, despite appearances. What Simple does is to define a whole shed load of "suggested values" for @rendition using a valList in the ODD, which begins like this:
<valList mode="add" type="semi"> <valItem ident="simple:allcaps"> <desc>all capitals</desc> </valItem> <valItem ident="simple:blackletter"> <desc>black letter or gothic typeface</desc> </valItem> <valItem ident="simple:bold"> <desc>bold typeface</desc> </valItem> <valItem ident="simple:bottombraced"> <desc>marked with a brace under the bottom of the text</desc> </valItem> <valItem ident="simple:boxed"> <desc>border around the text</desc> </valItem>
So it *looks* like we are defining a whole shed load of private URIs, hoorah. But nowhere is there a <prefixDef> that tells me what the "simple" prefix means i.e. how to map eg "simple:blackletter" to the appropriate CSS! Nor indeed is it clear where such a beast would reside. Maybe one day the TEI will provide a server from which recognised CSS mappings for these private URIs could be recovered, but I am not holding my breath. So, despite appearances, we have to conclude that these things are not really private URIs at all, but rather MAGIC CODES. In which case, really they ought to be being supplied on a @rend attribute...
It gets worse. The current schema includes a schematron constraint which says that the value of @rendition MUST be either a local pointer starting with '#' or a magic code starting "simple:". So I cannot define my own prefixes either. All I can do is provide the missing <prefixDef>s myself, which seems a bit hard on the Simple user.
At the moment the documentation is tactfully silent around this issue, or was until I introduced a brief explanation of how prefixDef works. Should I now expand this to spell out that users of Simple are expected to provide their own mappings for such of the proposed @rendition values as they choose to use? Or that Simple just provides these things like that, go figure ?
And where should they put their mappings? In the header of the document? But then they might as well be defined locally using xml:id and a regular # pointer (especially since you can't put a colon inside an xml:id value). In some other document we're not going to talk about? (My eyeballs, at least, are now rolling)
On 7/14/16 5:42 AM, Lou Burnard wrote:
I've added the valList into the teiHeader of the simple ODD document itself. This means that a simple document wishing to say e.g. <p rendition="simple:bold"> can do so iff it includes in its header a prefixDef element associating "simple" with the TEI Simple ODD. Which in turn means we should decide on a canonical web location for same, so that the document can tell people how to do it.
How about www.tei-c.org/Simple/tei_simple.odd ? Pointing, of course, to http://www.tei-c.org/release/xml/tei/Exemplars/tei_simple.odd
Setting up a directory Simple on the website would also give us a place to park background information about Simple, what is XML, the history of the project, and other stuff I have ruthlessly purged.
I think you'll want the canonical web location to be http://www.tei-c.org/Guidelines/Customization/Simple/ with the ODD living at http://www.tei-c.org/release/xml/tei/custom/odd/tei_simple.odd That would follow the structure of the other customizations ( http://www.tei-c.org/Guidelines/Customization/ ). I'm happy to create http://www.tei-c.org/Guidelines/Customization/Simple/ whenever you're ready and link to it from http://www.tei-c.org/Guidelines/Customization/ . Kevin
Well, I am happy to defer to the webmaster's wisdom, but I don't understand why the "real" address should not be http://www.tei-c.org/release/xml/tei/Exemplars/tei_simple.odd Is the URL with "custom" in it yet another redirection, or a copy, or what? At a first glance, it has the same files as Exemplars, but they are sorted into different folders for odds, schemas, templates, etc. For some reason. On 14/07/16 16:12, Kevin Hawkins wrote:
On 7/14/16 5:42 AM, Lou Burnard wrote:
I've added the valList into the teiHeader of the simple ODD document itself. This means that a simple document wishing to say e.g. <p rendition="simple:bold"> can do so iff it includes in its header a prefixDef element associating "simple" with the TEI Simple ODD. Which in turn means we should decide on a canonical web location for same, so that the document can tell people how to do it.
How about www.tei-c.org/Simple/tei_simple.odd ? Pointing, of course, to http://www.tei-c.org/release/xml/tei/Exemplars/tei_simple.odd
Setting up a directory Simple on the website would also give us a place to park background information about Simple, what is XML, the history of the project, and other stuff I have ruthlessly purged.
I think you'll want the canonical web location to be
http://www.tei-c.org/Guidelines/Customization/Simple/
with the ODD living at
http://www.tei-c.org/release/xml/tei/custom/odd/tei_simple.odd
That would follow the structure of the other customizations ( http://www.tei-c.org/Guidelines/Customization/ ).
I'm happy to create http://www.tei-c.org/Guidelines/Customization/Simple/ whenever you're ready and link to it from http://www.tei-c.org/Guidelines/Customization/ .
Kevin
Ah, I had assumed you made up the path http://www.tei-c.org/release/xml/tei/Exemplars/ , but I see now that it really exists and, as you note, has some but not all of the same files as the directories I was referring to. Everything under http://www.tei-c.org/release/ is created by the release process, which, as I recall, includes both a snapshot of the directory structure found in GitHub and also some files (like schemas) created as part of the process and put into new directories created for this purpose. I'm not sure which is more stable or more correct, so to speak. I only suggested these URLs because that would keep a parallel structure with the links already at http://www.tei-c.org/Guidelines/Customization/ . Those links on that page predate my term as webmaster, so at some point someone decided to link to things in the "custom" directory instead of the "Exemplars" directory. If Exemplars is better, I'm fine with updating the links at http://www.tei-c.org/Guidelines/Customization/ . K. On 7/14/16 1:13 PM, Lou Burnard wrote:
Well, I am happy to defer to the webmaster's wisdom, but I don't understand why the "real" address should not be http://www.tei-c.org/release/xml/tei/Exemplars/tei_simple.odd
Is the URL with "custom" in it yet another redirection, or a copy, or what? At a first glance, it has the same files as Exemplars, but they are sorted into different folders for odds, schemas, templates, etc. For some reason.
On 14/07/16 16:12, Kevin Hawkins wrote:
On 7/14/16 5:42 AM, Lou Burnard wrote:
I've added the valList into the teiHeader of the simple ODD document itself. This means that a simple document wishing to say e.g. <p rendition="simple:bold"> can do so iff it includes in its header a prefixDef element associating "simple" with the TEI Simple ODD. Which in turn means we should decide on a canonical web location for same, so that the document can tell people how to do it.
How about www.tei-c.org/Simple/tei_simple.odd ? Pointing, of course, to http://www.tei-c.org/release/xml/tei/Exemplars/tei_simple.odd
Setting up a directory Simple on the website would also give us a place to park background information about Simple, what is XML, the history of the project, and other stuff I have ruthlessly purged.
I think you'll want the canonical web location to be
http://www.tei-c.org/Guidelines/Customization/Simple/
with the ODD living at
http://www.tei-c.org/release/xml/tei/custom/odd/tei_simple.odd
That would follow the structure of the other customizations ( http://www.tei-c.org/Guidelines/Customization/ ).
I'm happy to create http://www.tei-c.org/Guidelines/Customization/Simple/ whenever you're ready and link to it from http://www.tei-c.org/Guidelines/Customization/ .
Kevin
participants (3)
-
James Cummings -
Kevin Hawkins -
Lou Burnard