norman.walsh.name: Comments on /2004/09/16/annotationMarkup http://norman.walsh.name/2004/09/16/annotationMarkup/comments.atom 2004-09-18T01:02:25Z Comment 1 on /2004/09/16/annotationMarkup http://norman.walsh.name/2004/09/16/annotationMarkup#comment0001 2004-09-16T18:48:34Z 2004-09-16T18:48:34Z Dave Pawson b46b0bd3946a0e2c96f45361a4be380edcd98ed6

I like the idea of a single element, with or without structural content. Rationale, its simpler. Structure is only needed on occasion. Then I could go on at great length explaining (for instance) some geekish phrase/word, with a structured explanation, or simply expand on an acronym to its full meaning.

I'm not altogether happy about the markup being 'within' the item being discussed, but can't put forward any rational explanation, so I'll see how it pans out. Could be that I'm too used to seeing markup around the content being marked up?

 Comment 2 on /2004/09/16/annotationMarkup http://norman.walsh.name/2004/09/16/annotationMarkup#comment0002 2004-09-17T11:44:19Z 2004-09-17T11:44:19Z Jirka Kosek a127c52a9381790d9bed58840c8508308ba33c22 http://www.docbook.cz

Dave I think that I can uderstand you position. I am also not completely reconciled with proposed syntax for annotation. Currently annotations are placed *inside* elements that are annotated. This make hard to distinct what is really annotated. I think that I will more like something like: 

<annotation>
  <abbrev>XML</abbrev>
  <description>eXtensible Markup Language</description>
</annotation>
This approach explicitly markups annotation and object that is annotated. Processing will be also very easy. If you want to get text of abbreviation you simple ask for content of abbrev element. This very easy in contrast to structure proposed by Norm, where content of abbrev element contains both abbreviation and its annotation. So to extract abbreviation text you must concat text value of all nodes except nested annotation element nodes.

Of course my approach has also its drawbacks. Almost all of schema languages (except RNG I think) are unable to express that annotation/abbrev is accepted only on places where abbrev is accepted while annotation/ulink is permitted only on place where ulink is normally permitted and so on.

Maybe someone will bring some completly new miracle markup for annotations into a place. I hope.

 Comment 3 on /2004/09/16/annotationMarkup http://norman.walsh.name/2004/09/16/annotationMarkup#comment0003 2004-09-18T01:02:24Z 2004-09-18T01:02:24Z John L. Clark c2db710b57d9f9476110584cb2a18aec65eb2fcf

Norm,

You echo some of the core questions that I've had pertaining to DocBook in general. I will mention them here, although they are off-topic with respect to annotations. If you feel their discussion should be taken to the DocBook list, well, we can do that.

What is the purpose of the distinction between para and simpara? By a given author's choice, a para can reduce to a simpara (which happens fairly often), or can be semantically richer when needed. What's the semantic value of providing a named differentiation? The question extends to the other examples you highlight; if an img is adequate for HTML, and interpretable as being block or inline according to context, why can't DocBook do the same for mediaobject? Essentially, why can't its caption be rendered or not depending on the context (block or inline) of the mediaobject? Relating it back to annotations, why can't one serve both functions according to context? There may be (read: probably is) an obvious use-case here that I'm missing, but I'd like to see it and reflect upon it.