LISTSERV mailing list manager LISTSERV 16.0

Help for ZNG Archives


ZNG Archives

ZNG Archives


[email protected]


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ZNG Home

ZNG Home

ZNG  January 2007

ZNG January 2007

Subject:

Re: SRU Version 1.2 draft specification

From:

"Edward C. Zimmermann" <[log in to unmask]>

Reply-To:

SRU (Search and Retrieve Via URL) Implementors

Date:

Sat, 27 Jan 2007 23:32:49 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (150 lines)

Quoting Edward Summers <[log in to unmask]>:

> On Jan 26, 2007, at 8:28 AM, Edward C. Zimmermann wrote:
> > - Secondly, XHTML is not XML.
>
> I don't want to take this too far out of context, but why do you say
> XHTML isn't XML?

XHTML is not the same thing as XML and that XHTML is not even a well-tamed
conforming application of XML.

XHTML is also an application and contains a lot of application level
stuff as well as semantics etc. and some of it is defined outside of XML.

>
>    XHTML documents are XML conforming. As such, they are readily

While a well-formed XHTML document is well-formed XML and as such XML
conforming, one can't define XHTML in XML, viz. I can define a well
founded XML based around XHTML that is not well founded XHTML.

The work into XHTML was initially work into a SGML based HTML.  XML
is not SGML. Since XML was envisioned as NOT a replacement for SGML but
as a formalization of the simplified tag and entity normalized SGML many
of us were using in our projects and applications we assumed that there
was SGML behind the scenes to define things. Our intent was not to replace
SGML but to create an easy entry path. Fundamental was the notion that a
well-formed document should be parseable in and of itself, that is, without
its DTD. Without DTDs, however, there is no way to define exclusions so XML
does not (and can't) have them.

Look at the Anchor tag: A
<A HREF="http://www.nonmonotonic.net/>BSn's NONMONOTONIC Lab</A>
is fine but while
<A HREF="http://www.nonmonotonic.net/><A HREF="http://www.bsn.de/">BSn</A>'s
NONMONOTONIC Lab</A> might be fine XML its clearly NOT good XHTML.

Anchors in XHTML are not to be nested.

There is a lot more.. even in the way documents are parsed.. Look at
<script> sections.

> viewed, edited, and
>    validated with standard XML tools. [1]

Actually I can define bad XHTML (just as I can define bad RSS) that passes
as valid by the popular XML tools.

-- I can't stress often enough: the Web is a mess. I mention RSS since I'm
sucking and parsing a lot of RSS in http://www.ibu.de and the vast majority
of ALL RSS I'm looking at don't conform to the standard they claim to conform
to. Show me a BLOG or so-called CMS system that produces RSS and I'll show you
invalid RSS that passes through as valid through all the standard RSS validation
software.

Back to order...
Imagine a document structure

Person
  \
 Name
 \  \
Last First

What's the difference in search context between

<PERSON><NAME><LAST>Zimmermann</LAST><FIRST>Edward</FIRST></NAME></PERSON>
and
<PERSON><NAME><FIRST>Edward</FIRST><LAST>Zimmermann</LAST></NAME></PERSON>

beyond the order of mark-up? Is one right and the other wrong?

Don't

<LAST>Zimmermann</LAST><FIRST>Edward</FIRST>
and
<FIRST>Edward</FIRST><LAST>Zimmermann</LAST>

probably define the exact same data in a RBMS? They are both just
the product of different report templates to generate an XML record.
Since SRU/W is also about interfacing to an RDBMS without XML then
how can we talk about Zimmermann being before or (ignoring tags)
adjacent to Edward?

If we want to talk about XHTML how about

<META NAME="DESCRIPTION" CONTENT="An example">

What's the difference between it and

<META CONTENT="An example" NAME="DESCRIPTION">

The standard says that order (and even process) does not matter.
In HTML/XHTMLi we, I think, all agree that it would be wrong to
attach a semantic meaning.

The META elements don't enter into the application rendering side of
things so let me ask:

What's the difference between the Dublin core

<meta name="DC.subject" xml:lang="de" content="Meeresfruechte" />
<meta name="DC.subject" xml:lang="en-GB" content="seafood" />
<meta name="DC.subject" xml:lang="fr" content="fruits de mer" />

(I lexi-ordered the languages by their locales)

<meta name="DC.subject" xml:lang="en-GB" content="seafood" />
<meta name="DC.subject" xml:lang="de" content="Meeresfruechte" />
<meta name="DC.subject" xml:lang="fr" content="fruits de mer" />

(I ordered them by my preferences)

Does the order of the META siblings in XHTML mean anything?

I can understand the utility and want (sometimes) of "document order". That's
why I support search by byte offsets within the original document (whatever
format the input was as long as its a document). Critical, however, for me
is the utility to search (also ordered) for "terms" in the same field (tag)
instance (named, named with path or unnamed). Searching for "out" and "spot"
in the same "line" of one of Shakespeare's plays is, after all, not the
same question as to find records where a line contains "out" and a line
contains "spot".

That search (using each play as a record) would produce the set:

`The Life and Death of King John'
`The Tragedy of Julius Caesar'
`The Tragedy of Macbeth'
`The Tragedy of Coriolanus'
`As You Like It'
`The Merry Wives of Windsor'
`The Tragedy of Antony and Cleopatra'

(with 55 hits alone in the first record)

while the former produces just one play:

`The Tragedy of Macbeth'
and the line: "Out, damned spot! out, I say!--One: two: why"
as spoken by LADY MACBETH in ACT V SCENE I.

-- 
-- 
Edward C. Zimmermann, Basis Systeme netzwerk, Munich
Office Leo (R&D):
   Leopoldstrasse 53-55, D-80802 Munich,
   Federal Republic of Germany
http://www.nonmonotonic.net

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

July 2017
October 2016
July 2016
August 2014
February 2014
December 2013
November 2013
October 2013
February 2013
January 2013
October 2012
August 2012
April 2012
January 2012
October 2011
May 2011
April 2011
November 2010
October 2010
September 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
October 2009
September 2009
August 2009
July 2009
May 2009
April 2009
March 2009
February 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager