Well, there isn't really much to show. Say I have a processing instruction
for my FOP application:
<?FOP pdf_version="1.2"?>
I can declare FOP as a NOTATION and associate it with an external entity:
<!NOTATION FOP SYSTEM "http://www.jtauber.com/fop/">
>I was wondering what these system identifiers contain. Are they validation
>routines that would check syntax of the content of elements with which
they
>are attached. (provided the notations are used in attributes as you
>suggested in your example) eg. would the system identifier
>http://www.schema.net/usdate.not check the element content with which it is
>attached for USDATE syntax?
They really just provide a way of naming notations (which is why a PUBLIC
identifier is often used) but it *can* be an actual bit of code, or a
human-readable description of the notation.
The notation name itself (in the above example "FOP") provides a level of
indirection, like a namespace prefix. You might declare FOP to be a
different notation to what I do. But if we both declare FOP to be
http://www.jtauber.com/fop/ then we are talking about the same notation.
In the case of USDATE, we could adopt a convention (and this is partly what
schema.net is intended for so send in those notation requests) that dates of
the form MM/DD/YYYY have the notation with external id
"http://www.schema.net/notations/usdate" (or whatever)
The URI needn't point to a meaningful resource, the key is the URI itself,
not the resource being referenced (although it would make sense to at least
make it a file with a human-readable description of the notation). In this
case, the application would need to know the URIs of notations it can
handle.
The external id could be referring to a Python function, or a Java class
implementing a notation interface, either of which might validate the given
content.
Hope this helps.
James