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

RE: Not quite an I-D announcement

• To: "Simon St.Laurent" <simonstl@s...>,<xml-dev@l...>
• Subject: RE: Not quite an I-D announcement
• From: "Keith W. Boone" <keith@w...>
• Date: Tue, 29 Oct 2002 10:16:24 -0500
• Importance: Normal
• In-reply-to: <r01050400-1021-A8F47148EAED11D690FC0003937A08C2@[192.168.124.21]>
• Reply-to: <keith@w...>

Simon,

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:

INTRO:
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.

JUSTIFICATION:
To communication expectations to an XPointer processor.

SYNTAX:
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.

PROCESSING:
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
supported
	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

FUNCTION LIBRARY:
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.

FEATURES:
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)
xpointer(id(pointer-to-failure-case))

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.

	http://URI/SCHEME-NAME/supported

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.


Keith




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@s...]
Sent: Monday, October 28, 2002 10:23 PM
To: xml-dev@l...
Subject:  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
http://simonstl.com/ietf/draft-stlaurent-xinclude-frag-00.html

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
http://simonstl.com/ietf/draft-stlaurent-xmlns-local-frag-00.html

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
XPointer.

--------------------------------------
The XPointer content-type() Scheme
http://simonstl.com/ietf/draft-stlaurent-content-type-frag-00.html

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
identifier.

---------------------------------------

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
down.


-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 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>

• Follow-Ups:
  • RE: Not quite an I-D announcement
    • From: "Simon St.Laurent" <simonstl@s...>

• References:
  • Not quite an I-D announcement
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: Re: XML Object Serialization
• Next by Date: RE: Not quite an I-D announcement
• Previous by thread: Re: Not quite an I-D announcement
• Next by thread: RE: Not quite an I-D announcement
• Index(es):
  • Date
  • Thread