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

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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


Subject: Re: [docbook-tc] annotation proposal


----- Original Message ----- 
From: "Norman Walsh" <ndw@nwalsh.com>
To: <docbook-tc@lists.oasis-open.org>
Sent: Thursday, April 14, 2005 4:48 PM
Subject: Re: [docbook-tc] annotation proposal


> / "Bob Stayton" <bobs@sagehill.net> was heard to say:
> | By using two different attachment mechanisms for the
> | two annotation elements, the distinction between them
> | is made even stronger.  I think that is a good thing.
> | I don't think <alt> needs any mechanism for
> | doing remote annotations or reuse of annotations.
> | But <annotation> does.  
> 
> On the whole, I think that's a fine proposal. Some questions and
> comments, in no particular order.
> 
> 1. I agree we should make the attributes CDATA. That allows, in principle
> at least, refersto="somefile.xml#someid"

Yeah, I was wondering about extending the connections to
other documents, but I didn't want to go there yet.  
I don't want to end up with RDF.  8^)
 
> 2. I'm not real wild about the name 'refersto'. What about 'annotates'?

Yeah, I kept reading it as "refer sto".  I think "annotates" is 
much better.

> 
> 3. Having both directions explicit means you can get mismatches. What
> does this mean:
> 
>   <para xml:id='p1' annotations='a1 a2'>...
> 
>   <annotation xml:id='a1' refersto='p1'>...
>   <annotation xml:id='a2' refersto='p2'>...
> 
> Is it an error? Does it mean the relationship is 1-way for a2 and
> two-way for a1? Does it make sense? Is that what users will want? We
> could also propose that they were always two-way and the processor was
> required to build the union.

No, it is not an error.  I should have made it clear that
I meant that either direction establishes the association.
Using both directions is just a convenience.  

So it means "the p1 para and the a1 annotation have an
association, and the p1 para and the a2 annotation have
an association.  The a2 annotation has an association
with a p2 element, which we can't see yet."
The only potential error here is if there is no element
with xml:id="p2".

> 
> 4. Is there any relationship between extended XLink and annotations?

I'm not proposing any.  I think that adds to the complexity,
and we would have to examine what would be gained by it.
 
> 5. Are annotations required to have an xml:id or a refersto?

No.  I think it should be possible to create annotation elements
and link them later.  Also, since a link can be established in
either direction, neither attribute would be required, although
an <annotation> won't be connected unless it has one or the other.
 
> 6. Is this allowed? How is this processed?
> 
>   <para>Hello<annotation>...</annotation> world.</para>

It is allowed, if we say that an annotation element can
appear just about anywhere.  Because it has no attributes,
the <annotation> in this example is not associated with
any element, not even the para it is inside.  In the
proposed scheme, all annotation elements are out-of-line,
they can appear anywhere, and their location means nothing.
They are connected only through the attributes.  The para
is simply a holding tank for the annotation element, and is
not otherwise associated with it.  To associate it with the
para, add the appropriate attributes.  Perhaps that is the part
of this proposal that people will have a hard time with.

How is it processed?  I have no idea.  The schema assigns
no semantics to <annotation>.  I guess the default processing
should be that an <annotation> element is ignored.

> 7. More generally, where are annotations allowed?

I'll go out on a limb here and say anywhere that an
indexterm is allowed.  I think we will have to look more carefully
at the implications, if people agree that this is a useful
design.

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net





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