[tei-council] conformance draft

Fri Mar 23 04:57:48 EST 2007

Conal, you've made a great deal of sense in all your comments. Thanks
for taking the time to argue your points so clearly.

On 3/22/07, Conal Tuohy <Conal.Tuohy at vuw.ac.nz> wrote:
> James Cummings wrote:
>
> > I recognise that
> > it creates a barrier to use of the customisation mechanism.
>
> That's perhaps true, in the first instance.
>
Everyone, after the call earlier this week I volunteered privately to
James to take an existing customization that I've been working on and
have it "namespaced" by the council meeting, just to see how much of a
barrier this actually is to people (like me) with middle-of-the-road
tech skills. This particular customization is designed to be plugged
into a METS file, so there is another layer to contend with there as
well.

Dot

> However, it can also make customisation much easier.
>
> If a customisation has been made using a namespace then it will be
> easier to combine with other customisations.
>
> I envisage a situation where encoders may pick a set of 2 or 3 existing
> customisations want to combine them together. Perhaps an
> "image-annotation" customisation might be mixed with a "CIDOC-ontology"
> customisation, an "AppInfo" customisation, or whatever. If these
> customisations used namespaces, then they could be combined more or less
> just by sticking them together.
>
> Whereas if they did not use namespaces, they might produce name
> collisions, and it would be necessary to resolve the conflicts, and
> define a new customisation independently.
>
> In summary, the non-use of namespaces tends to make customisations
> non-reusable, and makes document interchange harder.
>
> > I'm not entirely
> > convinced that it truly impairs human readability.  Having a
> > few namespace
> > prefixes might actually clarify things more.  I'm entirely
> > used to xml:id now as
> > an attribute.
>
> I agree. It may be seen as added clutter, but it may also be seen as a
> useful visual hint: if an encoding project has defined a new attribute,
> it's because they have some special requirement. Having a namespace
> prefix may help to draw their attention to the attribute, making it
> easier to find when reading the TEI. This is certainly my own
> experience.
>
> In any case, if namespace prefixes are seen as a barrier, then a
> customisation can rename ALL the TEI elements into a new namespace, and
> then add new elements to that namespace. Instance documents could then
> use a default namespace to qualify names, so there'd be no need for
> namespace prefixes. e.g.
>
> <TEI xmlns="tag:www.nzetc.org,2007:my-example-namespace">
>         <teiHeader>
>                 <myAdditionalSomethingDesc>
>                         ...
>                 </myAdditionalSomethingDesc>
>         </teiHeader>
>         <body>
>                 <gloop/>
>         </body>
>         ...
> </TEI>
>
> i.e. a "renaming extension" schema.
>
> Cheers
>
> Con
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>

-- 
***************************************
Dot Porter, University of Kentucky
#####
Program Coordinator
Collaboratory for Research in Computing for Humanities
dporter at uky.edu          859-257-9549
#####
Editorial Assistant, REVEAL Project
Center for Visualization and Virtual Environments
porter at vis.uky.edu
***************************************