[MEI-L] <div> in header
Axel Teich Geertinger
atge at kb.dk
Fri Oct 30 16:25:01 CET 2015
I meant <creation> of course, not <date> :-)
Personally, I prefer using <eventList> rather data-like, but I am aware that it may used in a more loosely-structured manner.
O course things are separated as they are; it's just that there isn't a single node I can select to get all the text contained in <p> elements, which is what I need in order to edit them in a Rich Text Editor. Anyway, let's just leave it as it is; my workaround seems to do the trick.
/axel
________________________________
Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu]
Sendt: 30. oktober 2015 15:03
Til: Music Encoding Initiative
Emne: Re: [MEI-L] <div> in header
The model of <history> is
<content>
<rng:zeroOrMore>
<rng:ref name="model.headLike"/>
</rng:zeroOrMore>
<rng:optional>
<rng:ref name="creation"/>
</rng:optional>
<rng:zeroOrMore>
<rng:choice>
<rng:ref name="eventList"/>
<rng:ref name="p"/>
</rng:choice>
</rng:zeroOrMore>
</content>
which, I believe, clearly separates its content into data-centric (creation) and free-form (eventList and p) components. <creation> contains information about the place and date of creation of the text in a fairly rigid way
<content>
<rng:zeroOrMore>
<rng:choice>
<rng:text/>
<rng:ref name="date"/>
<rng:ref name="geogName"/>
</rng:choice>
</rng:zeroOrMore>
</content>
while the <eventList> and <p> group offers a wider range of possibilities.
I don't think there's a need to wrap the eventList/p constellation because they're already cleanly separated from <creation> by the order of the model components. It seems to me that there's little benefit in introducing another level of hierarchy in the markup. But, I've been wrong before and I'm always willing to be convinced. :-)
I'd prefer *not* to use <div>, but wouldn't object to wrapping <eventList> and <p> if a suitable name can be found soon. Since we're breaking backward compatibility with the next release, it would be better to make this change sooner than later.
--
p.
__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Axel Teich Geertinger [atge at kb.dk]
Sent: Friday, October 30, 2015 5:36 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] <div> in header
Hi Perry & Andrew
Thanks for clarifying this for me. I understand what you mean. Perry, I think your distinction between "text" and "the text" is an important one which perhaps could make the guidelines clearer on this point.
I clearly wanted to wrap text, but not "the (document) text". What causes me headache are header elements that may contain both "structural" or "data-like" as you say, and "text-level" elements. <history> for instance has children like <date> and <eventList> (structural) and <p> (text). If only these elements had a "structural" element to wrap the text-like parts, they would be much easier for me to handle. It wouldn't have to be <div>, which I now understand; we could invent a new one or perhaps use <notesStmt>/<annot> (though that may possibly require a somewhat broader description of <notesStmt>; the guidelines say that it "collects any notes providing information about a text additional to that recorded in other parts of the bibliographic description").
As I said, I can work around the issue, so it's not a matter of great importance to me. But perhaps it may be worth considering.
Best,
Axel
________________________________
Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de] på vegne af Roland, Perry D. (pdr4h) [pdr4h at eservices.virginia.edu]
Sendt: 29. oktober 2015 20:55
Til: Music Encoding Initiative
Emne: Re: [MEI-L] <div> in header
The definition "Major structural division of *text*, such as a preface, chapter or section" was intended to convey the idea that <div> is to be used in *the text*. That is, <div> is available for text within the <body>, but not in the header. I'd be grateful for suggestions for improving the definition so it's more clear.
Structuring metadata above the paragraph level is the function of the various metadata elements themselves. Allowing the recursively nest-able <div> element within the header would discourage the "data-like" treatment that metadata requires; that is, a hierarchy that's as flat as possible. Where internal structure is permitted, it's often facilitated by the use of elements that may appear as content of a <div>, such as <p> or list-Like elements -- items that either contain phrase-level text or can occur within phrase-level text.
Renditional info in the header is also strictly at the phrase level, when for instance <rend> is permitted within <altId> and <classCode> to accommodate typographical features like superscripts and subscripts.
I think <div> already is aligned with its counterpart in HTML. That's another reason why it isn't allowed within the header.
--
p.
__________________________
Perry Roland
Music Library
University of Virginia
P. O. Box 400175
Charlottesville, VA 22904
434-982-2702 (w)
pdr4h (at) virginia (dot) edu
________________________________
From: mei-l [mei-l-bounces at lists.uni-paderborn.de] on behalf of Andrew Hankinson [andrew.hankinson at mail.mcgill.ca]
Sent: Monday, October 26, 2015 12:12 PM
To: Music Encoding Initiative
Subject: Re: [MEI-L] <div> in header
On Oct 26, 2015, at 4:48 AM, Axel Teich Geertinger <atge at kb.dk<mailto:atge at kb.dk>> wrote:
Hi Andrew
I can do a workaround by wrapping the contents in a <div> before passing it to the text editor and stripping it off again with XSLT on saving. Nevertheless, I am not sure I agree that header contents is never intended to be rendered. After all, the header may contain such information as transcriptions of a source's title page.
I think the distinction I was trying to say is that the information in the header is never rendered *directly* -- that is, it's never intended to be related (in a positional sense) to the content in the document. Of course, the information in the header can and should be intended to be shown to the users, but I think the positioning and display of header text should be left to the software rendering it.
We are rendering loads of header information in our catalogues. I agree that exact placement of text blocks doesn't seem to be a likely thing to do in the header, not even within the title page transcriptions (I have no idea what kind of coordinates would make any sense unless we implement a detailed page layout specification; but that's definitely not a road I want MEI to go down). MEI does, however, already allow quite some text formatting within <p> such as font style, size, and color, so header content may already contain some rendering information.
I would even go so far as to say that anything that has to do with font, sizes, etc. should be held in the "<music>" section. Holding rendering information in the header seems like a recipe for confusion.
But more important, I do not see why <div> should be used for positioning and other rendering purposes only. On the contrary – the MEI guidelines say:
<div> (division) – Major structural division of text, such as a preface, chapter or section.
This is exactly the structuring mechanism I would like to see in the header as well: structure on a larger scale than <p>.
Yes, this is problematic. Personally, I would like to see <div> take on more of the HTML-like definition of a block-level element, to cause less confusion to encoders who are used to the HTML-like behaviour: "It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so."
-Andrew
Best,
Axel
________________________________
Fra: mei-l [mei-l-bounces at lists.uni-paderborn.de<mailto:mei-l-bounces at lists.uni-paderborn.de>] på vegne af Andrew Hankinson [andrew.hankinson at mail.mcgill.ca<mailto:andrew.hankinson at mail.mcgill.ca>]
Sendt: 25. oktober 2015 23:00
Til: Music Encoding Initiative
Emne: Re: [MEI-L] <div> in header
Personally, I think of <div> being used to position rendered text like in HTML. So having it in the header would be problematic, since that information is never intended to be "rendered" directly.
This is somewhat related to a recent discussion on GitHub: https://github.com/music-encoding/music-encoding/issues/272
-Andrew
On Oct 25, 2015, at 1:23 PM, Axel Teich Geertinger <atge at kb.dk<mailto:atge at kb.dk>> wrote:
Hi
Is there any particular reason why <div> elements are not allowed anywhere in the header?
I am asking this because I want to use a Rich Text Editor (tinyMCE) for blocks of text in the header, for instance in <annot> or <history> within <work>. This type of editor requires that the editable content is wrapped in a single element (like <p> or <div>). It is not good at handling mixed content. Of course i could use <p> as the wrapper, but then I would have to have one editor instance for every paragraph, if I want more than one paragraph of text.
I actually think that allowing <div> in <history> could also make the structure a little clearer. As it is, <history> may contain <head>, <creation>, <eventList> and any number of <p>s. Perhaps it would be nice to be able to wrap all non-structured text in a single <div> to separate it from the more structured elements <creation> and <eventList>?
Best,
Axel
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
_______________________________________________
mei-l mailing list
mei-l at lists.uni-paderborn.de<mailto:mei-l at lists.uni-paderborn.de>
https://lists.uni-paderborn.de/mailman/listinfo/mei-l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20151030/9f5aec87/attachment.html>
More information about the mei-l
mailing list