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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] xml:href, xml:rel and xml:type

From cited document:

"For Web architecture, a design choice has been made that metadata
received in an encapsulating container MUST be considered authoritative
and used in preference to metadata found by inspection of the data,
declared by embedded metadata, or provided by external reference.
Although this design choice is generally applicable to any container
format, including archival formats that encapsulate other data, the most
significant interpretation for Web architecture is that representation
metadata found within the header fields of a received message shall be
considered authoritative for the representation encapsulated within that

And that is a system constraint.  IOW, on the web/off the web is
systemically meaningful and this is why:  governing authority at the
point of making meaningful choices, deciding probability in advance.

Expectations are powerful.  Explain to your boss (as I was a few minutes
ago) why ID/IDREF relationships are meaningful as XML typed
relationships in the XML entity but are NOT hyperlinks and why.  Anyone
writing a history should devote a chapter or three to this precise issue
because almost everything that follows technically after 1996 at the
publishing of the MIME/Multipart specification diverges here.  The
network definition seizes authority over the document itself.  It is the
system handler taking charge over the content being handled.   

As long as all that is wanted is a control handler, this is fine.  As
soon as the data (say href-marked) is applied as a different kind of
metadata (eg, to denote an abstract relationship), it goes to complexity
hell with question "is this de-referenceable?" being the signpost up
ahead and you are in the twilight zone.

A description of the contents of the Cheerios box may be litigable but
it isn't affective once the cereal is in the bowl of milk.  Thus
self-descriptive data formats.


-----Original Message-----
From: Rushforth, Peter [mailto:Peter.Rushforth@NRCan-RNCan.gc.ca] 
Sent: Thursday, April 19, 2012 9:51 AM
To: John Cowan; Liam R E Quin
Cc: Len Bullard; xml-dev@lists.xml.org
Subject: RE: [xml-dev] xml:href, xml:rel and xml:type


If XLink is to support the web , they should be added for sure.

Although they are strictly advisory, according to this note



> -----Original Message-----
> From: John Cowan [mailto:cowan@ccil.org] On Behalf Of John Cowan
> Sent: April 19, 2012 01:58
> To: Liam R E Quin
> Cc: Rushforth, Peter; Len Bullard; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] xml:href, xml:rel and xml:type
> Liam R E Quin scripsit:
> > Indeed, different HTTP clients (browsers) might receive different 
> > formats, depending on the Accept: HTTP headers they send.
> Which is why XInclude has xi:include/@accept and 
> xi:include/@accept-language headers, so that including 
> documents can specify a particular version of included 
> documents to try to fetch.
> These could be added to XLink 1.2 if anyone cared.
> -- 
> Not to perambulate                 John Cowan <cowan@ccil.org>
>     the corridors                  http://www.ccil.org/~cowan
> during the hours of repose
>     in the boots of ascension.       --Sign in Austrian 
> ski-resort hotel

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS