[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: A thought on XLink in PIs for processing directives

  • To: 'Jason Diamond' <jason@i...>, xml-dev@l...
  • Subject: RE: A thought on XLink in PIs for processing directives
  • From: "Bullard, Claude L (Len)" <clbullar@i...>
  • Date: Wed, 9 Jan 2002 13:38:17 -0600

thought processing
Most of that is spilt milk now.  OTOH, PIs are open 
to those who want to develop alternatives to specs 
and still use XML.  It is a very neat feature from 
that viewpoint.

PIs were heavily criticized in days of olde as 
a way to pollute content.  In effect, they were 
a way to avoid precisely that.  But those who 
used them were sidestepping the idea that all 
systems should interoperate based on a formal 
public declarations.  That is the One World System 
viewpoint.  It is seductive somewhat like a 
one world religion or government but inimical 
to the very idea it originates in:  the ability 
to create information free of local system 
constraints.  Ultimately, the information owner 
has to choose.  XML, the W3C, etc., should only 
have a limited ability to control those choices 
and then only insofar as a system definition 
enables interoperation without unduly limiting 
choice.   The W3C and XML are there to enable potential; 
not control markets.

The owner has to choose wisely.  As noted often 
here, XML is as underpowered as it is because 
a syntax spec enables interoperability right 
to the edge of limiting other choices.  Otherwise, 
one becomes a wraith in the tunnels muttering 
"My precious!" after surrendering all options 
to the FrameworkFromMordor.

len orc

-----Original Message-----
From: Jason Diamond [mailto:jason@i...]

> PIs were a common means in SGML systems to create links.
> IDEAS/IADS worked like that originally.  It was the
> interpretation of some that links are not really content,
> they are a process/function.   It is a theoretical issue at the
> very heart of darkness for hypertext systems.

To me, it seems obvious that the xml-stylesheet PI is not content since it's
only allowed in the prolog of an XML document (before the document element).
The xsi:schemaLocation attribute, on the other hand, is content (although it
will most likely be ignored by processors other than schema validators).

Unfortunately, just like namespace declarations, xsi:schemaLocation can
appear on any element in an instance document--though it must appear before
an element or attribute is encountered in the namespace described by the
schema found at that location. Personally, I agree with Michael and would
have rather seen something like an xml-schema PI (or a more generic xml-link
PI) in the prolog--one for each namespace the document contained. This keeps
the processor-specific data out of the document and makes it really easy to
see exactly what the document contains from a really high-level point of
view.

<?xml-schema namespace='http://example.org/'
href='http://example.org/schema.xsd' type='application/xsd+xml'?>



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.