[dsdl-discuss] Re: Fw: [relaxng-user] NRL: schemaType for schemas in XML

We need a mechanism that applies generally. I don't see why two attributes
should be required, one for non-XML schemas and one for XML schemas. The
fact that the mechanisms can get out of step, aka HTML's type, is
irrelevant. The fact that the validate element it is attached to requires a
specific action to be performed at the time of processing to me signifies
that you need a mechanism for determining whether or not you are likely to
be able to successfully process the data prior to fetching it. If you know
you can't process a particular XML schema, or any non-XML schemas, then you
should be able to apply fallback without calling anything.

Martin Bryan
IS-Thought: Thinkers for the Information Society
29 Oldbury Orchard, Churchdown, Glos. GL3 2PU, UK
Phone: +44 1452 714029 Fax: +44 1452 859991
E-mail: martin@is-thought.co.uk

----- Original Message -----
From: "MURATA Makoto" <murata@hokkaido.email.ne.jp>
To: <dsdl-discuss@dsdl.org>
Cc: <sewe@rbg.informatik.tu-darmstadt.de>
Sent: Tuesday, February 03, 2004 4:32 AM
Subject: [dsdl-discuss] Fw: [relaxng-user] NRL: schemaType for schemas in
XML

When media types of referenced schemas are unavailable and schemas are
not XML, we need some other metadata for specifying schema languages.
"schemaType" of NRL is (in my understanding) allowed only for this case.
Andreas proposed to allow "schemaType" even when referenced schemas are
XML and media types are available.

I personally do not see strong reasons ("reject a schema of unknown type
before fetching a copy from a remote server" is not a strong enough
reason for me). Moreover, "schemaType" and referenced schemas may
be inconsistent. But I would like to hear how others feel about this.

This is very similar to the attribute "type" of
anchor elements of HTML. The HTML 4.01 spec says:

This attribute gives an advisory hint as to the content type of
the content available at the link target address. It allows user
agents to opt to use a fallback mechanism rather than fetch the
content if they are advised that they will get content in a
content type they do not support. Authors who use this attribute
take responsibility to manage the risk that it may become
inconsistent with the content available at the link target
address.

Makoto

Forwarded by MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>
----------------------- Original Message -----------------------
From: "Andreas Sewe" <sewe@rbg.informatik.tu-darmstadt.de>
To: "[Relax NG]" <relaxng-user@relaxng.org>
Date: Tue, 27 Jan 2004 18:34:12 +0100
Subject: [relaxng-user] NRL: schemaType for schemas in XML

----
Hopefully this is the place for discussion about NRL as well.
According to James Clark's NRL document the "validate" element's
"schemaType" attribute is meant to indicate the type of the specified
schema iff its not in XML. Otherwise its type can be automatically
detected from the schema's namespace URI.
While this is certainly true I wonder whether it's worthwhile to allow
for an (optional) indication of a schema's type even in case of a XML
schema. Thus a validator can e.g. reject a schema of unknown type before
fetching a copy from a remote server.
I envision somthing like RDDL's use of XLink's "role" attribute to
indicate the nature or type of the schema specified. Thus one can write
<validate schema="xhtml.rnc"
 schemaType="http://www.isi.edu/in-notes/iana/assignments/media-types/
 application/x-rnc">
as well as
<validate schema="xhtml.rng"
 schemaType="http://relaxng.org/ns/structure/1.0">
Any comments?
Regards,
Andreas Sewe
_______________________________________________
relaxng-user mailing list
relaxng-user@relaxng.org
http://relaxng.org/mailman/listinfo/relaxng-user
--------------------- Original Message Ends --------------------
--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)
--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)