PIs in xml:schema

Don Park wrote:
> 
> I entirely agree with your opinion.  Liam's view is that of concern over
> misuse where I am more concerned with functionality.  I believe XML
> community can benefit from a guideline for proper use of PI as well as some
> mechanism for registering PI target names.   Meanwhile we need to encourage
> HTML browsers to recognize PI so that we do not lose this important feature
> of XML.

Let me reiterate that in my mind the best way to handle this would be to
allow these floating element types in XML schemas. So in a sense I am for
the removal of PIs ... once they are properly replaced. I can think of an
element-syntax replacement that would be far superior. Here is the
beginning of a specification:

The big problem with PIs is that they are not declared, namespace managed
or internally structured (according to XML). Our replacement would have
to allow a document to declare that it was using XHTML with "style binding
inclusion extensions" or "xyz formatter page break extensions" or "zyx
editor cursor position extensions".

The fundamental characteristic of a floating element type is that an
application that did not know about the floating element type could
choose not to see elements of that type or their content. In this case 
the term "application" includes stylesheets and schemas. Further, it 
should be possible to identify a floating element type without reading 
the document's schema(s) -- or even reading the schema for the element 
type.

As a very (very) rough strawperson proposal, lets say that we have a
declaration: 

<mydoc xmlfloat:ns="http://.../someschema.xsd">

This syntax should be aligned with 

 a) the NS spec, 
 b) the xml:schema declaration syntax and
 c) the xml:schema ns/schema importation syntax.

For now, we'll use this syntax.

This declaration would say:

 a) elements in this namespace are floating elements
 b) they should conform to the referenced schema

Floating elements would be invisible to the "main" schema and to each
other. So conceptually a different instance of the schema processor would
be required for each included schema.

Some layer between SAX and a "float smart" application (including an XSL
processor, XML Schema validator or DOM engine) would filter out floating
elements that had not been specifically requested. You could register with
the layer what floating elements you are interested in or simply ask for
all of them.

Stylesheets would register for the floating elements that they are
interested in and only see those and no others. This is superior to PIs
because today PIs mess up things like node-list-first...you might think
that the title of a chapter would be its first node but not if there is a
PI there!

DOM-based applications would register recognized float schemas with the
DOM-constructor (or ask for them all). Helper functions/methods would
allow filtering at runtime.

If we had all of this then I don't see why we would need the "<?" in the
document. An author doesn't really care whether a particular element is a
floating element or not. So we could dump PIs as-we-know-them.

Why are floating elements better than PIs?

 * they would have a schema language
 * they would reuse element syntax (more consistent)
 * they could contain XML-defined sub-elements
 * their namespace would be managed
 * their basic syntax is already standardized (as XML 1.0 elements)

I think that this is superior to PIs.

Note: SGML's inclusions have a bad reputation because they can be applied
at any point in a document type. That means that if you move a paragraph
from one place to another its validity could change based on its content.
It is arguable whether this is a good idea. Plus there is no standardized
way to filter them out.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Earth will soon support only survivor species -- dandelions, roaches, 
lizards, thistles, crows, rats. Not to mention 10 billion humans.
	- Planet of the Weeds, Harper's Magazine, October 1998

Received on Thursday, 13 May 1999 19:05:51 UTC