I'm forwarding this message (with permission) from the www-html list where
XHTML 2.0 is being discussed.
I'm interested in peoples' views on the potential problems outlined below
of moving from using a '.' to a ':' as the separator between the
'namespace' prefix and the property name.
My personal views are that
- the backwards incompatability issue is significant but something we can
decide to live with
- the 'parsing' argument (not needing to parse a string like 'dc.date') is
neither here nor there - indeed is probably something that should be
discouraged
On the final paragraph, my view is that metadata creation is likely to be
done by a mix of software tools and by hand, therefore the most
human-intuitive syntax should be used. I would argue that, at this stage,
dc:date is more intuitive than DC.Date (given other DCMI documents). On
the other hand, parsing embedded DC is always done by software. So,
although the cost might appear to be higher because one is likely to be
parsing lots of documents, the effort is all handled by software, not by
humans - therefore the actual cost is lower.
Any other views?
Andy
--
Distributed Systems, UKOLN, University of Bath, Bath, BA2 7AY, UK
http://www.ukoln.ac.uk/ukoln/staff/a.powell +44 1225 383933
Resource Discovery Network http://www.rdn.ac.uk/
---------- Forwarded message ----------
Date: Mon, 19 May 2003 06:54:55 -0400
From: Ernest Cline <[log in to unmask]>
To: [log in to unmask]
Cc: [log in to unmask]
Subject: Re: XHTML2 and metainformation
Resent-Date: Mon, 19 May 2003 06:55:13 -0400 (EDT)
Resent-Date: Mon, 19 May 2003 12:09:34 +0100
Resent-From: [log in to unmask]
Andy Powell wrote:
> On Sat, 17 May 2003, Ernest Cline wrote:
>
> > Andy Powell wrote:
> >
> > > In any case, it is worth noting that
> > >
> > > - all DC element names start with a lower-case letter (i.e. date rather
> > > than Date)
> >
> > What DC does with its element names should not be a concern for XHTML.
> > As far as XHTML is concerned, DC could choose to use UPPERCASE,
> > CamelCase, or lowercase, or be case insensitive. I used DC.Date rather
> > than dc.date in my example simply because that is what the version of
> > the DC standard I used recommended.
>
> Again, that's fine... but DC examples were being used and, if, those
> examples were to make it thru into the finished recommendation then it
> would be good if they reflected current DCMI naming policies.
Makes perfect sense, provided that as seems almost certain, the DCMI
working draft reaches recommendation status before XHTML2 does.
> > > - it seems sensible to move to a syntax that more closely mirrors the
> > > encoding of DC in XML and RDF/XML (i.e. dc:date rather than DC.Date)
> >
> > Seems more like marketing than practicality to me. Switching to a
> > colon instead of a period does not gain any new functionality and does
> > make backwards compatability more difficult.
>
> Well, FWIW the reaction on the DC architecture mailing list to this
> proposal seems to have been quite positive. People seem to recognise that
> the use of a period to separate a 'namespace prefix' (which is effectively
> what the 'DC.' in 'DC.Date' is) is oddly different from the other main
> encoding syntaxes used to carry metadata (XML and RDF/XML).
>
> > Also, continuing to use
> > periods instead of switching to colons would seem to me to make the
> > task of writing ECMAScript or Java that interacts with meta-data
> > slightly easier.
>
> Ah, I hadn't spotted that. Can you explain why?
The main reason a switch to colon in this context would make things
slightly more difficult is that since such scripts or programs will
need to be backwards compatible, an extra comparison to be done while
searching for the separator in DC meta-data embedded in (X)HTML <meta>
elements.
Secondly, since the period is used as the object dereference marker, an
ECMAScript script that wished to collect all of an (X)HTML's <meta>
embedded meta-data could possibly use the raw name such as "dc.date"
directly in the script instead of having to parse it beforehand. This
is an extremely minor point as the parsing should be done anyway in
order to be able to handle unexpected name values.
Neither is a major concern, if the switch to colon provided sufficient
benefit. Switching to colon would make inserting meta-data easier to
do, but keeping period will make collecting meta-data easier to do.
The small per document benefit in either case is more likely to be
noticable when working on large groups of documents. Collection of
meta-data is more likely to be done on groups of documents than
insertion of meta-data. As a result. I personally fail to see
sufficient benefit to the change, hence my preference for keeping
period as the separator.
|
