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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Not quite an I-D announcement

[ Lists Home | Date Index | Thread Index ]


It seems that you want something more like a "pragma" scheme to cover all
three cases.  Something like the following, though cleaned up a bit:

The pragma() scheme is intended to be used within the XPointer Framework[12]
to support the addressing of nodes within XML documents. Pointer parts using
the pragma() scheme will always fail, as they do not identify portions of an
XML document, but they can communicate (though not enforce) expectations for
processing of later parts of an XPointer.

To communication expectations to an XPointer processor.

The scheme name is "pragma". The scheme data syntax is as follows; if scheme
data in a pointer part with the pragma() scheme does not conform to the
syntax defined in this section, it is an error and the pointer part fails.

pragma() Scheme Syntax:
  ptrpart	::=    pragma( feature, value [, required] )
  feature	::=    scheme-ns-uri / feature-name

where "scheme-ns-uri" is the URI used to identify the scheme that the pragma
affects [and must be identical to the scheme NS URI if it exists], and
feature-name is a string that identifies the feature that is affected.
Value is a string that specifies the desired setting.  Required is yes|no,
and if omitted, defaults to no.

An XPointer processor supporting this scheme will:
	ignore the feature/value setting if the feature is unknown or not supported
and required is no.
	signal an error if _required_ is yes and the feature is unknown or not
	signal an error if the value specified is not a legal setting for the
specified feature
	replace the feature/value settings in the execution context if the setting
value is legal

The "string getPragma(string)" function will be added to the XPath function
library for XPointer processors that support this scheme.  This function
will return the value of a given pragma in the execution context.

This scheme defines the following features:

	http://URI/pragma/supported	[NOTE:  Need to pick a URI]

Whose value can only be "yes".

To test for support of the pragma scheme, create a two part link:
	pragma(http://URI/pragma/supported, no)

Since no is not a legal setting value for http://URI/pragma/supported, the
end result should be an error if pragma is supported.  Otherwise, the end
result will succeed with the second pointer part.


Whose value can only be yes for any SCHEME-NAME that is supported by the
XPointer processor.  To detect support for a given scheme in the XPointer
processor, the following pointer should succeed without generating an error.

	pragma(http://URI/SCHEME-NAME/supported, yes, yes)

Other XPointer schemes or specifications can defined additional features.

	Et cetera and so forth.


Engineering is what happens when science and
mathematics meet politics.  Products are what
happens when all three meet reality.

-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
Sent: Monday, October 28, 2002 10:23 PM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Not quite an I-D announcement

I misremembered the date for the IETF Internet-Drafts cutoff (this
morning, 9am EST), so managed to write a trio of initial XPointer scheme
drafts that now can't be published through the Internet-Draft process
until November 22 or thereabouts.

These documents specify schemes for use in XPointer-based fragment
identifiers. These schemes, like other XPointer Framework schemes, are
designed primarily for use with the XML Media Types defined in RFC 3023,
to identify locations within a given XML representation of a resource.

If anyone would like to make comments on the initial versions of these
documents prior to their submission as Internet-Drafts, I'd be happy to
hear them.  In many ways, this makes more sense than having a single
person publish initial Internet Drafts anyway, and many of these ideas
emerged from various xml-dev discussions.

The three not-quite drafts are:
The XPointer xinclude1() Scheme

The xinclude() scheme notifies an XPointer processor whether the creator
of the XPointer intended for XInclude 1.0 processing to take place.

The XPointer xmlns-local() Scheme

The xmlns-local() scheme notifies an XPointer processor that it should
include all of the namespace binding context defined for the element
containing the XPointer in the namespace binding context for the

The XPointer content-type() Scheme

The content-type() scheme notifies an XPointer processor whether the
creator of the XPointer intended for a particular pointer part to apply
to a resource representation which uses a particular MIME content type


All three of these drafts are designed primarily to ask questions rather
than provide conclusive answers in any event, so limbo may be an
appropriate status.  I consider all of these completely experimental at
this stage, but it seems worth publishing them now, while the work on
RFC 2396 revision is just getting started and as XPointer work winds

Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid: is another possibility altogether

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>


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

Copyright 2001 XML.org. This site is hosted by OASIS