Entities and namespaces in XSchemata

[Simon St.Laurent]

[Forwarded for Peter Murray-Rust]

[Toby Speight]
>Wouldn't limit one's ability to constrain (e.g.) GIs to reasonable
>values. I envisioned <ElementType Name="mol">, where the attribute
>"Name" was constrained to be a NMTOKEN, to mirror the constraint in
>ordinary XML DTD language. Am I mistaken in thinking that entities
>are not expanded in NMTOKEN values?

[PMR]
I think this is exactly the sort of question that we shall be debating in
2-3 days. I hadn't thought of NMTOKEN - I can see the attraction of it. But
it wouldn't allow the namespace tweaking.

>OTOH, I'd be happy with asking a XSchema -> DTD transformer to add or
>change namespace prefixes as part of the translation process.

>[BTW, your use of <Seq optional="no" repeatable="no"> implies either
>assumption of the WebTC or not constraining the values to a token group.
>I'd go for <Seq optional="required" repeatable="not-repeatable"> in the
>traditional idiom. Or maybe use minimum/maximum occurance specifiers.]

I have no preconceived ideas :-) This was just to concentrate our minds on
the sort of level the discussion will be at. IOW we are deciding (a)
whether we stick with the DTD limits ('', ?, *, +) or allow more. We MUST
allow translation to/from DTD, so if we allow occurrence="42", it will get
translated to '+' in DTDs.

[Mathew Gertner]
>So if we postulate that parameter entities will be replaced in XSchema by a
>more generic linking mechanism, the problem of partial validation seems to
>be simply and elegantly solvable. For example (modifying one of Peter's
>previous posts):

><xschema>
><ElementTypeDef id="greetings">
><ContentSpec>
><Seq optional="yes" repeatable="yes>
><ElementType>politeform</ElementType>
><ElementType xml:link="simple" role="XSchema"
>href="http://www.xschema.org/library/person.xsc#id(person)">person</ElementT
>ype>
></Seq>
></ContentSpec>
></ElementTypeDef>
></xschema>

>(I changed the outer element type name from "ElementType" to
>"ElementTypeDef". Do we want the GI to be the same for both the definition
>itself and for references to other element types within the content model?)

Again, a point for us to resolve

>Instead of using an entity reference, the link attributes point to the
>appropriate definition of the content type for the "person" element. This is
>way better than parameter entities because it uses a unified link syntax
>*and* is far more flexible. I can whip up a quick schema just by throwing
>together a few elements and pointing to their appropriate definitions using
>URIs of whatever flavor. Certainly better than copying and pasting parameter
>entities.

Yes. This simply requires us to make sure that the appropriate XLink
attributes are added to certain ElementTypes in the XSchema. I would
*strongly* suggest that we did not - at this stage - attempt to define what
is at the other end of the link (any more than namespaces). In fact I
wouldn't be surpried if we could borrow the namespace semantics for this :-)


>Another interesting factor is that these links could just as easily be
>included in the document itself. So if I have a document which lacks a
>schema, but want to validate the "greetings" portion (for which I have a
>schema), I could link into the schema at that point:

[... good example snipped ...]

>In this case, only the "greetings" element and its content would be
>validated. This is really incredibly powerful considering its simplicity:
>the content in question actually gets validated against two separate schemas
>(actually just bags of element type definitions) in two different files.

You are discovering, as we all are, that XLink is a very exciting and
powerful tool. Note that the links don't have to be in the XSchema OR the
document! [They can be extended OOL links.] So simply creating XSchemas as
XML documents - without any semantics - allows anyone to add them later
with XLink. [BTW I think we should just note the power of what is unleashed
here and not try to work out all its possibilities.]  I also expect that
where we write XLink and where we write RDF may be a matter of style of
syntax rather than fundamental differences. I gather from private
conversations at Paris that it is expected that RDF will be (or at least
can be) implemented with XLink.


>This does complicate the spec a bit, although the principle is actually very
>simple. The only real decision is whether it is kosher to use XLink/XPointer
>in a schema definition. To me it would seem a crying shame not to allow
>this, whatever the implications for the "layering" of the architecture. Of
>course, for this we need a linking engine, but at least the effort can be
>leveraged for both schemas and documents, demonstrating why a unified syntax
>makes sense in the first place.


I think we should allow for it, because it can always be added by other
means, but not constrain its use. Exactly like namespaces. 'the XLink
attributes is provided to locate/identify the semantic resource [if we like
that phrase].' This allows for experiments just like namespaces allow(ed)
experiments.

	P.





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)